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GLOSSARY 



active fori^irouisid progremi: a foregjoufad progrmm is active 
if it is residerat in memory, connected to internapts, or 
in Ihe process of being entered into tiae sysfe^u via a 
}XEQ control connmond- 

area: a contigjjo«s portion of a random access device fijat 
contains files of some reiai&d nature, 

iaackgrotind area: tliat area of core storage allocated to 
botch processing. This area iroay be ci^eckpoinled for 
use by foreground pfrogroms. 

background program: ony pn^^rom executed wntder jMkonitor 
control in the background area when no interrupts are 
active. These progranas are entered through the batch 
prQcessing input stream- 

batch processing: a computing technique in swliich sijnilar 
programs are grouped together and processed or exe- 
cuted in a singJe run so as to effect efficient utiliza- 
tion of the computer, 

channel status table: a table of ei^t wonJs per SYSGEN- 
defined I/O channel that reflects the hardware condi- 
tion of each I/O channel - 

checkpoTnted fob: a partial ly processed background fob 
that has been saved in secondary storage along with 
all registers and other "environment" so that the |ob 
can be restarted at its interrupted point. 

clock counter: a memory location that records the progress 
of real time or its approximation, by accumulating 
counts produced by a (clock) count pulse interrupt. 

close: terminating the use of an item (such as a file) and 
performing certain clean up operations to provide for 
Its future reuse or the reuse of its resources- 
control command: any control message other than a key-in. 
A control command may be input via any device to 
which the system command input function has been 
assigned (normally a card reader). 

control message: any message received by the Monitor that 
is either a control command or a control key-in, 

count zero interrupt: an interrupt level that is triggered 
when an associated (clock) count pulse interrupt has 
produced a zero result in a clock counter. 



device-file rnmher (OFN): a logical fnelhod of referring 
both to a physical peripheral device ar»d to a collec- 
tion of information t^JKSut the device. The device file 
number indicates the ord^^ in which devicesare initially 
defined at SYSGEN, For example., the first device 
defined must always be a keyboard printer (DEN 1). 

device ruamGz an identifier used at SYSGEN time for an 
actual physical l/G device that is composed of two 
elements: a device type which Is a two-character code 
for a particular class of peri|:^eral devices, and a de- 
vice number which is a two-digit hexadeclroal repre- 
sraitation of the physical unit noiuber associated with 
a device. 

device unit number: an integer valwe coded into a 

FORTSiAN IV prognam to reference peripheral devices- 
Standard device unit numbers can be equated to device 
file numbers {see obove) either at SYSGEN time or 
through 1 ASSIGN commands, 

directory: a table of names ond addresses of files on a ran- 
dom access device that enables the system to locate a 
file when given only its nanr»e and area- 

disobled: the condition of an interrupt level wherein the 
level may advance from the anned to the waiting state 
when triggered by an interrupt pulse, but the level 
cannot cause a program interruption until it is enabled; 
it thus remains in the waiting state until it is allowed 
to interrupt the program. 

disarmed state: the state of an interrupt level that cannot 
accept an interrupt Input signal. 

disk pock: a secondary storage system of removable rotating 
memory- For most RBM purposes, disk pack and RAD 
are synonymous unless otherwise noted- 
enabled; the condition of an interrupt level wherein 
the level is not inhibited from advancing from the 
waiting state to the active state except for priority 
considerations- 
end action: that action that takes place at the completion 
of an I/O operation. This usually includes the entry 
of a special routine that was specified when the re- 
quest was made, 

end record: the last record to be loaded In an object 
module or load module. 



critical task: a task whose in^ortance is hl^ enough thot 
no attempt should be mode to run without it in the 
event of a serious error. 

dedicated memory: core memory locations reserved by the 
Monitor for special purposes, such as interrupts and 
real-time programs- 



error severity level code: a code Indicating the severity 
of error noted by the processor. This code is con- 
tained in the final byte of an object module. 

execution location: a value replacing the origin of a 
relocatable program that changes the address at which 
program loading is to begin. 



external interrupt: one of the class of interrupts that are 
associated with special systems equipment. These 
interrupts are "external" to the basic computer sys- 
tem and are associated with functions that are de- 
fined according to the requirements of a particular 
installation. 

external interrupt inhibit: the bit, in the program status 
doubleword, that indicates whether (if 1) or not (if 0) 
all external interrupts are inhibited. 

external reference: a reference to a declared symbolic 

name that is not defined within the module in which 
the reference occurs. An external reference can be 
satisfied only if the referenced name is defined by an 
external load item in another module. 



file control table: contains information about all device 
files in the RBM system and is indexed by device-file 
number. 



file name; a name for a permanent file that is defined 
either at SYSGEN or later through the RAD Editor. 



installation inpuf parameter: any input parameter used during 
System Generation to direct the formation of an RBM 
system. 

internal interrupt: one of the class of interrupts that are 
supplied with a standard computer system, or are op- 
tional additions associated with dedicated functions 
(such as power fail-safe). These interrupts are 
"internal" to the basic computer system. 

interrupt trigger signal: a signal that is generated, either 
internal or external to the CPU, to interrupt the nor- 
man sequence of events in the central processor. 

I/O block: a contiguous amount of RAD or disk space that 
contains records of blocked or compressed files. All 
I/O blocks are the same size (K:BLOCK) and always 
begin on a sector boundary. K:BLOCK also specifies 
the size of core blocking buffers. 

I/O control table: a table containing the device-specified 
input/output control doublewords and other information 
necessary for RBM I/O services. There is a one-to-one 
correspondence between the I/O control table and file 
control table. 



flawed track: a disk pack track that contains a flaw mark 
in the header as well as the address of an alternate 
track. 

foreground area: that portion of memory dedicated speci- 
ficially for RBM, service routines, and foreground 
programs. 

foreground program: a program that executes in the fore- 
ground area of core and can utilize all privileged 
services. 

foreground task: a body of procedural code that is associ- 
ated with (connected to) a particular interrupt. 

GO file: a RAD file of Relocatable Object Modules 

(ROMs) formed by a processor. This is a default input 
file when no file name is specified. 

granule: a record beginning on a physical sector boundary, 
used as a unit of allocation for random RAD or disk 
pack files. A granule is usually synonymous with a 
sector on a device, but may be defined (on a file basis) 
to be equivalent to a partial sector, one sector, or 
several sectors. 

idle state: the state of the Monitor when It is first loaded 
into core memory or after encountering a IFIN control 
command. The idle state is ended by means of an 
S key-in. 

inhibited interrupt: a condition of an interrupt that pro- 
hibits it from entering the active state. 

input/output interrupt: an interrupt triggered by the stan- 
dard I/O system of the computer. 



I/O control subtable: same as I/O control table except 
that the subtable is RAD specific. 

library input: input from the device to which the LI (li- 
brary input) operational label is assigned. 

library load module: a load module that may be combined 
(by the Overlay Loader) with relocatable object mod- 
ules, or other library load modules, to form a new ex- 
ecutable load module. 

link editing: the process of combining separately compiled 
or assembled program modules, relocating them, link- 
ing them to defined library toutines, and producing an 
absolute executable load module. 



loading: the process of reading an executable program (see 
link editing above) from secondary" memory to absolute 
locations in main memory. 

load map: a listing of significant information pertaining to 
the storage locations used by a program. 

load module: an executable program formed by using 
Relocatable Object Modules and/or library object 
modules as source information. 

logical device: a peripheral device that is represented in 
a program by an operational label (e. g. , BI or BO) 
rather than by a specific physical device name. Or, 
a SYSGEN mechanism for reserving logical groups of 
DFN's fora combination of foreground and background 
use to accomplish information transmission between 
tasks without the use of any real peripheral device. 



1. INTRODUCTION 



RBM CHARACTERISTICS 

The Xerox 530 and Sigma 2/3 Real-Time Batch Monitor 
(RBM) is the major control element in the operating system. 
It supervises and services simultaneous foreground programs 
and background batch programs without interfering with the 
real-time response capability of the foreground. 



RESIDENT SECTION 

The resident portion of RBM consists of the following parts: 

• Several independent tasks that are connected to the 
hardware interrupts (e.g., the real-time tasks). The 
tasks are not reentrant. They can communicate with 
each other and may use some of the monitor service 
routines. 

• Several reentrant monitor service routines that can be 
used by any task in the system. These are described 
in Chapter 4. 

• Standard system constants and tables (see Appendix C). 

• Input/output tables for constants and status information. 



NONRESIDENT SECTION 

The nonresident part of RBM consists of the system initiali- 
zation portion that is loaded at the time the system is cre- 
ated, monitor service routines, and device -dependent I/O 
routines for which a response is not critical. The initiali- 
zation portion selects the optional features of RBM and 
initializes the input/output constants. 



SYSTEM ENVIRONMENT 

In addition to the Monitor itself, the hardware -software 
environment of the operating system consists of the following 
major elements: 

• Xerox Model 530 or Sigma 2/3 computer system in- 
cluding (a) the required system RAD, (b) the selected 
number of hardware interrupts connected to various 
foreground tasks in user-determined priority sequence, 
(c) dedicated and commonly shared I/O devices. 

• Partitioned core memory (see Figure 1) divided into 

• A protected RBM area reserved for the RBM 
monitor. 
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Figure 1. Operating System 



Introduction 1 



logical record: a record that isa fixed measure of contiguous 
data (on a file basis), distinctive as being meaningful 
to the user. For blocked RAD files, logical records 
ore contiguous within blocks but need not be integral 
to a block. 

memory protection: the use of the optional protection 
feature that keeps unprotected background memory 
from altering protected foreground meaning. 

memory write lock: a one-bit write-protect field option- 
ally provided for each 256-word page of core memory 
addresses. 

Monitor: a program that supervises the processing, load- 
ing, and execution of other programs. 

nonresident foreground program: a foreground program ex- 
plicitly called from secondary memory that resides in 
the rvanresident foreground area of core memory during 
execution. The space thus occupied Is considered 
"active" and is protected by the Monitor from inter- 
ference by other activities. 

object deck: a card deck comprising one or more object 
modules and control commonds. 

object language: the standard binary language in which 
the output of a compiler or assembler is expressed. 

object module: the series of records containing the load 
information pertaining to a single program or sub- 
program. Object modules serve as input to the Over- 
lay Loader. 

open: the preparing of an item (such as a file) for initial 
use. 

operational label: a symbolic name used to identify a 
logical system device. 

operational label table: there are two tables: one for 
foreground and one for background. The tables con- 
tain the two-character operational labels that are used 
for reference by the RBM service routines and connect 
an operational label to a device file number. 

option: an elective operand in a control command or pro- 
cedure call. 

Overlay Loader: a processor that links and absolutizes 
elements of programs. 

overlay program: a segmented program in which the 
segment currently being executed may overlay the 
core storage area occupied by a previously executed 
segment. 

OV file: a RAD file that contains an executable program 
formed by the Overlay Loader if a program file name 
was not specified at load time. Used primarily to test 
new programs or new versions of programs. This is a 
default file when no output file is specified. 



physical device: a pheripheral device that is referred to by 
a "name" specifying the device type, I/O channel, 
and device number (also see "logical device"). 

postmortem dump: an optional listing of the contents of a 
specified area of core memory, usually following the 
abortive execution of a background program. 

primary reference: on external reference that must be 
satisfied by a corresponding external definition (capa- 
ble of causing loading from the system library). 

priority level: priority level of o task is dependent on the 
position of its associated hardware interrupt in the 
priority chain. 

RAD/disk areas: the allocation and definition of a RAD 
into specific areas during SYSGEN, each of which is 
labeled with a two-character mnemonic to expedite 
file management. 

Rapid Access Data (RAD) storage system: a secondary stor- 
age system of rotating memory. For most RBM purposes, 
RAD and disk pack are synonymous unless otherwise 
noted, 

real-time processing: data processing designed so that the 
results of the operations are made available in time to 
influence some process being monitored or controlled 
by the computer system. 

reentrant: that property of a program or subroutine that 
enables it to be interrupted at any point, employed 
by another user, and then resumed from the point of 
interruption. Reentrant programs are often found 
where there is a requirement for a common store of 
public routines that can be called by any user at 
any time. The process is controlled by the Monitor 
which preserves the routine's environment (registers, 
working storage, control indicators, etc.) when it is 
interrupted and restores that environment when the 
routine is resumed for its initial user. A reentrant 
routine never stores any intermediate values within 
itself. 

Relocatable Object Module: a program or subprogram that 
may be relocated and link edited to operate anywhere 
in core; that is, does not have absolute addressing. 

resident foreground program: a foreground program that is 
automatically loaded into a fixed area of foreground 
core memory every time the system is booted in. 

secondary reference: an external reference that rnay or 
may not be satisfied by a corresponding external def- 
inition (not capable of causing loading from the sys- 
tem library). 

secondary storage: any rapid access storage medium other 
than core memory (e.g., RAD or disk pack). 

segment loader: a Monitor routine that loads overlay seg- 
ments from RAD storage at execution time. 



semi resident foreground program; a foreground program 

explicitly called from secondary memory that resides 
in the resident portion of core memory during 
execution. 

service routines: Monitor-supplied services and opera- 
tions that can be called by an executing foreground 
program, or else by an executing background program 
(except for certain privileged function dedicated to 
foreground use). 

source deck: a card deck comprising a complete program 
or subprogram in symbolic EBCDIC format. 

source language: a language used to prepare a source 
program (and therefrom a source deck) suitable for 
processing by an assembler or compiler. 

symbolic input: input from the device to which the SI 
(symbolic input) operational label is assigned. 

symbolic name: an identifier that is associated with some 
particular source program statement or item so that 



symbolic references may be made to it even though 
its value may be subject to redefinition. 

system library: a group of standard routines in relocatable 
object language format, any of which may be included 
in a program being created. 

Task Control Block (TCB): part of the load module that 
contains the area required for context storage. The 
TCB is task-associated. 

temfXJrary files: those files that exist only until the current 
job step ends. They may, or may not, have existed 
prior to the start of the job. 

Temp Stock; an area of memory optionally created by 
the Overlay Loader for a user program and used by the 
Monitor and System Library routines. 

unsolicited key-in; information entered by the operator via 
a keyboard in response to a Control Panel interrupt. 



• A protected resident foreground area reserved for 
user foreground tasks. 

• A protected nonresident foreground oreo reserved 
for a single nonresident foreground program. 

• A protected public library area reserved for public 
library routines shared by foreground and back- 
ground tasks. 

• An unprotected background orea used by back- 
ground (non -real -time) processors, translators, and 
botch users' programs, and occasionally by fore- 
ground programs requi ring temporary use of addi - 
tional memory. 0n this case the foreground will 
checkpoint the background.) 

• The system RAD, allocatoble into permonent and tem- 
porory files. The permanent files contain all the back- 
ground RBM processors such as Basic FORTRAN IV or 
ANS FORTRAN IV, Extended Symbol, RAD Editor, etc., 
plus RBM itself. They may also contain user data and 
operational resident and nonresident foreground pro- 
grams that can be called into protected memory for 
processing. Temporary files are normally used as in- 
termediate scratch areas by processors or user programs. 

• A number of user foreground tasks that can be con- 
nected to hardware interrupts- Exomples of foreground 
tasks ore process control operations, real-time data ac- 
quisition and control, and low-speed telemetry applica- 
tions. The RBM Control Task is connected to the lowest 
priority hardware Interrupt in the system so that no 
background processing can delay foreground tasks. 

• Overlay Loader for linking and absolutizing segmented 
foreground and background programs that enables back- 
ground processors and user programs to overlay them- 
selves In core storage, and thus permitting programs of 
virtually unlimited size to be executed. 



FOREGROUND (High-Uvel Priority Response) 

Within the framework of the user-determined hardware 
interrupt priorities, foreground programs or tasks operate as 
independent entities, and the Monitor generally makes no 
attempt to Interject Itself between these tasks and their real- 
time furKtions. The Monitor services the foreground only 
on request, such as a coll to one of the monitor service rou- 
tines. The princlpolforegroundservlcesof theMonitororeto 

• Respond to I/O interrupts. 

• Respond to an operator's console request (such as 
queuing). 

• Supervise RAD file activity. 

• Optionally, supply a software version of multiply/ 
divide functions for configurations without multiply/ 
divide hardware. 



For RBM purposes, RAD ond disk pack are synonymous 
unless specifically stated otherwise. 



• Load a foreground program into memory from the RAD 
on request. 

• Provide the foreground with standard constants (see 
Appendix C). 

• AAake avoiloble o "mailbox" area of 32 memory loca- 
tions for communication between two or more foreground 
programs. 

The Interrupt priority sequence (described in detail In the 
respective computer reference manual) is the basis for the 
priority level of tasks in the RBM system. That is, the pri- 
ority level of a task is dependent on the position of the as- 
sociated hardware interrupt in the interrupt priority chain. 
Backgrour>d fobs in the system all have the some priority 
level. A background job is not connected to any interrupt 
level in the system. I.e. , its priority is below all hardware 
interrupt levels and is processed serially. 



BACKGROUND (tow-Level, No Priority) 

The primary function of the Monitor is to supervise and con- 
trol all those operations that take place in the unprotected 
background area by the following meons: 

1. Use only available foreground idle time for back- 
ground processing. 

2. Interpret control functions from control command card 
Images via the Job Control Processor. 

3. Supervise the loading and execution of all back- 
ground jobs and activities in unprotected memory. 

4. Provide simple background scheduling (first-in, 
first -out). 

5. Provide I/O services for the backgrourKi job stack. 

6. Inform the operator on the status of peripheral device 
operations. 

7. Test all background operations and processes for fore- 
ground protection violations and prevent the backgrourKi 
from altering or deloying foreground response or from 
using dedicated I/O devices. 



RBM processors and permanent user processors may be 
loaded onto permanent RAD files and then executed by 
control comnrand. Programs may also be loaded onto tem- 
porary RAD files for the duration of the present job. 



All programs must exist on the RAD in absolute core image 
form for execution. Relocatable programs, consisting of 
a root and one or more overlay segments linked by ex- 
ternal references, must be created by an Overlay Loader 
to link all modules and create the proper overlay struc- 
ture for execution. 



RBM Characteristics 



It is possible to create programs consisting of a root and one 
or more overlay segments through use of the Absolute Loader 
if there are no external references (see the !ABS command in 
Chapter 2 for other restrictions). 

Two levels of logical (rather than physical) device refer- 
encing are provided, enabling system configurations to 
change or expand without reprogramming. Further, through 
many device-independent features and use of standard medio 
formats, input and output con be directed to card equipment, 
paper tape equipment, or magnetic tape without changes in 
the user's program. 

For maximum flexibility and control of input/output, the 
user can optionally specify his own I/O Control Double- 
words and order bytes, perform independent error recovery, 
and be informed by RBM when an I/O operation has term- 
inated. Alternatively, for greater ease of programming and 
device independence, the RBM will create the lOCDs and 
order bytes and perform standard error checking and recovery. 

When multiprogramming with foreground tasks and back- 
ground jobs, the foreground has access to all privileged in- 
structions. The background is checked by both hardware 
and software to provide complete protection of a foreground 
program's use of core memory and peripheral operations. 



SECONDARY STORAGE MANAGEMENT 

The RBM operating system provides use of the RAD or disk 
packs for 

• Temporary and permanent files. 

• User and system files. 

• Sequential files (pseudo tape, where RBM performs all 
file management). 

• Random-access fi les (RBM performs I/O transfer and con- 
trols file limits, but user controls relative addressing). 

RAD/DISK PACK AREAS 

The concept of RAD/disk pack areas is a convention created 
primarily to expedite file management. RAD and disk pack 
areas are allocated during system initialization. Disk pack 
areas may also be allocated after system initialization, 
using the RAD Editor. The areas are labeled with two al- 
phanumeric characters, from the following list: 



SP 


BT 


BP 


Xn 


SD 


CP 


UP 


aa 


SL 


FP 


UL 





where n is a decimal digit and a is any letter combination 
except Xn. Note that the combination "SK" has a special 
meaning (described in "SYSGEN" chapter of Reference 
Manual 90 30 36) and is not an area mnemonic. 



The labels have the special meaning given in Table 1, 



Table 1 . RAD/Dfsk Areas 



Mnemonic 



SP 



SD 



SL\UL 



UP,FP,BP 



BT^ 



CP 



aa 



Xn 



Meaning 



System Processor area. Contains RBM and 
user-selected processors from the list given 
in Table 5 (the Overlay Loader is a man- 
datory processor). This area is searched 
whenever either a system processor or user 
processor is requested. 

System Data area. Contains files neces- 
sary for the execution of RBM. 

System Library and User Library areas. 
These are the only areas from which the 
Overlay Loaders will load library routines. 

User, foreground, background processor 
areas. Contains resident foreground pro- 
grams, foreground tasks, nonresident 
programs, semi-resident programs, and 
background programs. Area FP may only 
contain files of foreground or no-write 
protect codes and area BP may only con- 
tain files of background or no-write pro- 
tect codes. The UP area may have its 
area write protection specified during 
System Generation or RAD Editing. 
These areas and the SP area are searched 
when a processor is requested. SP, UP, 
and FP are searched (in the order given) 
for resident foreground programs, when the 
system is booted from the RAD. 

Background Temp area. Used for alloca- 
tion of temporary files. 

Checkpoint area. Used to store the back- 
ground environment when a background 
program is checkpointed by a foreground 
process. 

User data areas which contain any data 
the user desires, including program files. 

Xn areas are simitar to aa areas except 
that the user has the option to perform his 
own management of the entire area, thus 
allowing access to data arranged in non- 
standard formats. No disk pack verifica- 
tion is performed for an M (Mount) key- 
in (see "M Key-Ins" in Chapter 3). 



These areas receive defaultallocationsduring SYSGEN. 
Note that the SP and SD areas must be present fn the 
system 



RBM Characteristics 



PROCESSOR FILES 

Processor files are stored either as a single segment or as an 
overlay slruchjre. Overlay Loaders store the files on 
the RAD In core image form, ready for loading, and abso- 
lutized for the space they will occupy at execution. The 
processor files are loaded for execution via a processor con- 
trol commond. 



LIBRARY FILES 

Library files contain subprograms in a relocatable form. 
The files have specified entry points and are in the form of 
binary card images in Standard Object Language. 

There is one library file for the system area mnerrionic SL, 
and one for the user area nrMiemonic UL. Overlay Loaders 
can load selectively From one or both, in either order 
or priority. Although records within a subprogram are 
loaded sequentially, access to the individual subprogram 
is on a rondom (direct access) basis. 



DATA FILES 

Permanent data files may contain any kind of data and may 
be accessed sequentially or randomly, depending on how 
they were created. The user is responsible for reading them 
accordingly. 



FILE NAME 

Only permanent RAD files have a file name. Some names 
are entered into the dictionary for the appropriate area at 
System Generation; others are entered later by the RAD 
Editor. After the name is in the dictionary, an I ASSIGN 
control command or a call to MrASSIGN can equate either 
an operational label or o FORTRAN device unit number to 
this file name. 



OVERLAY CAPABIUTIES 

Under RBM, Overlay Loaders can be used to create over- 
lay programs for later execution in either the foreground or 
background.'' The overlay programs can be permanently 
entered (as a file) Into either the System or User Processor 
areas, or into a temporary overlay file (OV). Since they 
are stored on the RAD in absolute core image format, they 
can be quickly loaded into memory for execution. 

Each segment is created by an Overlay Loader from one or 
more object modules (assembly language, FORTRAN, or 
library routines). The control commands required to create 
the overlay segments are defined in the discussion of the 
Overlay Loaders. During execution, the Monitor service 



routine M:SEGLD is used to control both the loading and 
the transfer of control between various segments. 



TASK OlSMtSSAl 

The dismissal option allows for^round tasks to be auto- 
matically dismissed by RBM when they would otherwise be 
waiting at a high level for on-going I/O to complete. This 
feature allows automatic overlap of high level (i.e., 
foreground) I/O and low level CPU execution to the 
enhancement of low level throughput. The feature is con- 
trollable on a task basis or a system basis and requires very 
little core space. 



CHECKPOINT/RESTART 

The checkpointing feature permits a partially processed 
background job to be saved in secondary storage along with 
all registers and other environment. The vacated back- 
ground space is set to protected status and is then available 
to the interrupting foreground task for either instructions or 
temporary data storage. 

Checkpointing ensures continuity to the partially completed 
background job by not repositioning any background periph- 
eral devices, permitting all current background I/O activity 
to complete, and writing all of the background space onto a 
prespeclfled RAD area. 

Restart takes place when the previously checkpointed back- 
ground program is reloaded from the RAD and continues 
execution as though the interruption never took place. 



PUBLIC UBRARY 

Most of the support on FORTRAN and mathematic routines 
are reentrant.'' If an RBMsystem has several real-time fore- 
ground tasks that use a number of the same subroutines, the 
collectively-used set of subroutines can be loaded together 
into what is termed a Public Library. Thereafter, whenever 
the Overlay Loader processes a foreground or background 
program that references one of the "public" routines, it sets 
the appropriate branch to the Public Library. The Public 
Library is loaded into core whenever RBM is rebooted from 
the RAD. 

When one of the Public Library routines needs temporary 
scratch space. It requests space (via a call to M:RES) from 
the temporary stack of the task that is calling the Public 
Library routine. V\^en the library routine exits, the space 
is released via a call to M:POP. 



For a complete description of the Overlay Loaders, see the 
Overlay Loaders chapter. 



See the ANS FORTRAN IV Library Technical Manual, Pub- 
lication No. 90 18 35 for restrictions concerning library 
routines in the Public Library. 



RBM Characteristics 



REENTRANT ROUTINES 

In RBM usage, "reentrant" means that a subprogram (never 
a task) may be interrupted during execution, called again 
by the interrupting task, and later reentered and continued 
from the location of the former task. This is a last-in, 
first-out kind of reentrancy in keeping with the computer's 
priority interrupt system - 



ACCOUNTING AND ELAPSED TIME 

Background job accounting and provisions to limit the exe- 
cution time of a background job can be accomplished by 
specifying the JOBACCT option at SYSGEN. To correctly 
calculate the elapsed time for the background, the Moni- 
tor M.-SAVE routine changes the charge index to foreground 
at the first interrupting foreground task. M:EXIT restores 
the charge index v/hen return to background is sensed. 

JOBACCT is also used to limit the execution time of a back- 
ground program. The user may limit this execution time by 
using the ! LIMIT control command, and Clock 1 v^ill pro- 
vide v/atchdog services on the background program. 

When a !JOB control command is read, an entry is created 
in the accounting file (RBMAL,SD). The entry includes 
the start time, user name, and account number. The 
start time of the [ob is then logged on the LL device 
as mm/dd/yr hrmn. 



The time for a background job is recorded in the accounting 
file entry for that job. The IDLE account is updated to re- 
flect total idle time charges. After the IFIN control com- 
mand is read, all idle time is charged to the IDLE account. 

The following rules govern the operations of the Accounting 
Log: 

• A call to M:SAVE switches from the background to 
foreground time accumulation. 

• A coll to MrEXIT switches from foreground accumula- 
tion to background accumulation if a background job 
is executing. 

• AW key-in, M: WAIT request, or ! PAUSE command 
switches from foreground accumulation to idle time 
accumulation. An abort from an attended job switches 
the same way. An S key-in switches back to foreground 
accumulation from the idle accumulation. The M:EX1T 
to background switch charges to background. 

• A UOB or IFIN command writes out total accumulated 
times and resets times to zero. 

• The ET (elapsed time) is printed on LL each time JCP is 
read into the background and represents the total elapsed 
background execution time. 



At the completion of each activity, the accumulated 
elapsed time of background execution will be logged on 
the LL device as 



SYSTEM INITIALIZATION AND CREATION 



ET-mmm.mm (minutes) 

At the completion of the job (i.e., o new UOB or IFIN 
command) the current date and time and a job recap are 
logged on the LL device as 

mm/dd/yr hrmn BK=mmm.mm, 

FG=mmm.mm, ID=mmm.mm 



/her 



BK represents the total job time. The total time 
for a Job is defined as the time available to the 
background from the time the UOB control com- 
mand is read until the next UOB or IFIN com- 
mand is encountered. 

FG represents the amount of time used by inter- 

rupting foreground tasks during the job. 

ID represents the accumulated idle time incurred 

within the job. This could be a result of an 
M: WAIT request, a W key-in, I PAUSE command, 
or an attended job being aborted. 



The RBM system is created for a particular installation 
through a nonpermanent system generation (SYSGEN) pro- 
gram (see System Management Reference Manual 90 30 36). 

The user defines RAD areas, optional routines, peripheral 
devices, and operational labels. This is followed by a def- 
inition of the exact bounds on the foreground, monitor, and 
background memory areas, and the size of the RAD areas. 

Once the system is completely defined, the required routines 
are loaded and a rebootable version is written onto the 
RAD. 

If the system must be restarted later, the rebootable version 
is loaded from the RAD. A completely new system initiali- 
zation is necessary only if the above mentioned definitions 
must be changed. 

When the system is created, a version number is specified 
that will be printed on LL at the beginning of each job for 
reference. 



Most of the Xerox disk devices have manual switches that 
may be used to permanently protect certain areas. 



RBM Characteristics 



wm mms^ms mo m^sssm 



BASIC FORTMN IV 



REM suf^or+s ihe sdbsysfenie, processors, and for^round 
focilifies descriiaed below- Ihe sdbsystefus and fM-ocessors 
execute m the Jxickgrour»d area of core memory - 



Basic FORTRAN IV Is a cMie-pass compiler with capabilities 
extended beyc»id Basic FC^TRAN. ft cart compile large 
sowce programs by using tbe RAD for overlay to minimize 
core residence requirements, arwJ bos two fiocrting -point 
modes: standard precision and extended precision. 



sfMm/^m mmsumms 



OVERLAY LOADERS 

The Overlay Loaders form absolute binary overlay segments 
for later execution in either foreground or background 
areas- If a resident or nonresident fa-ogram can tolerate 
a loadirjg deloy of 20 to 1{X) ms, foreground or background 
programs of virtually unlimited size can be constructed 
with the Overlay Loader despite Mmitations in available 
core storage- 



ANS FORTRAN 

The Xerox ANS FORTRAN IV compiler provides a full 
FORTRAN IV capobility- ANS FC^TRAN IV is designed 
ior real-time reentrant usoge, as well as for norniai batch 
processing- It is upwards cotiF^tible with the Basic 
FC^TRAN IV language compiler. It meets ami exceeds the 
specifications given In the ANSI FORTRAN X3. 9-1966. 
This expanded version of the compiler adds language syntax 
sophistication that both simplifies problem solving arid 
allows for greater pr<:>gramming flexibility than earlier ver- 
sions of FORTRAN IV compilers. (Not available with 
Sigma 2 systems- ) 



RAD EDITOR 

The RAD Editor performs RAD allocation for permanent files 
and generates and maintains directories for the permanent 
RAD areas: System Processor area. System Library area. 
System Data area. User Processor area. User Library area. 
User Data area, and any aa areas and Xn areas- It allows 
dumping of files and mapping of all RAD areas, including 
checkpoint and temporary areas- 



UTILITY SUBSYSTEM 

The RBM Utility subsystem provides a universal media copy 
routine, object module editor, dump routine, and record 
editing by line or sequence number. 



RFG 



RPG allows users to perform batch ikita processing tasks 
using simplified prc^ramming techniques. Xerox RPG is an 
expanded version of corrventional RPGs that accepts ami 
processes IBM 1130, 1800, and 360/20 RPG specifications. 
RPG is useful for any installation with a need to 

• Create reports. The fixed program logic of RPG Is 
ideally suited for those installations that require one- 
time reports, since elaborate coding is not required for 
generating those reports. 

• Process inventory, payroll, or other commerical 
applications. 

Under Sigma 3, RPG requires the Extended Arithmetic 
(8119) feature. (Not available with Sigma 2 systems.) 



SORT 



LANGUAGE AMD SERVICE PROCESSORS 



EXTENDED SYMBOL 

The Extended Symbol assembly language processor (as- 
sembler) provides upward c<»npatibility with basic Symbol 
plus extended capabilities that include using the RAD for 
overlay to reduce core residence requirements- 

The processor accepts as input a source program coded in 
either Symbol or Extended Symbol, processes it, and out- 
puts an object module, diagnostic messages, an optional 
assembly listing, and an optional cross-reference listing- 



The Xerox Sort processor offers a generalized file sorting 
capability- Xerox Sort is a disk-oriented multiphase pro- 
gram that is overlayed to reduce memory requirements. The 
sorting technique used is a replacement-selection tourna- 
ment with a balanced merge of intermediate strings- (Not 
available with Sigma 2 systems-) 

COBOL 

Xerox 530 ANS COBOL offers a powerful and convenient 
programming language for implementation of business or 
commercial applications. Xerox 530 ANS COBOL is a 
subset of the X3-23 - 1973 ANS COBOL Standard and con- 
tains the following modules implemented at the first level: 

• Nucleus 

e Table Handling 



RBM Subsystems and Processors 



Sequential I/O 

Relative I/O 

Indexed I/O 

Inter-Program Communication 

Library 

Debug 

Additional features such as in-line diagnostics optional 
data map, procedure map, object listing and cross reference 
are included. 

The Xerox 530 ANS COBOL compiler is a two-pass pro- 
cessor using a segmented structure to minimize the core 
required for operation. The compiler runs in the back- 
ground under control of RBM. 

Sequential, Relative and Indexed files produced by 530 
COBOLare compatible with those produced by 530 RPG II 
Version COO. 

Under Sigma 3, COBOL requires the Extended Arithmetic 
(81 19) feature (not available with Sigma 2 systems). 



OPTIONAL FOREGROUND FACILITIES 



DEBUG 

The RBM Debug package provides the user with a debug- 
ging tool designed primarily for nonsegemented background 
programs but with a limited capability for debugging fore- 
ground programs. The Debug functions and commands are 
described in Chapter 12. 



XSP 



The Xerox Satellite Processor (SP) provides Xerox 530 or 
Sigma 3 computer sites with a capability for high-speed 
telecommunications with other host remote computer systems. 
Operating under either a Xerox 530 or Sigma 3 operating 
system, the Xerox Satellite Processor permits communication 
with any host Xerox computer running under the Control 
Program-Five (CP-V) operating system and non-Xerox host 
computers in accordance with the HASP Multi leaving 
Protocol. 

The basic function of the Satellite Processor is to move 
streams of sequential data from source devices or files to 
destination devices or files at the request of the operator, 
which provides the Xerox 530 or Sigma 3 user a highly con- 
venient means for utilizing the full resources of a larger 
host system or exchanging data with another HASP compat- 
ible workstation. Remote activities may take place concur- 
rently with local foreground and background processing, 
subject to device and resource availability. Spooling of 
remote data using magnetic tape is supported. (Alternately, 
a sequential disk file may be substituted for magnetic tape.) 

A Satellite Processor site can communicate with three gen- 
eral classes of remote sites: 

1. CP-V host. 

2. IBM host. 

3. Another Xerox workstation or IBM HASP compatible 
workstation. 

Support for up to four 7605 communications controllers Is 
provided. A single HASP host may regard the Xerox 
Satellite Processor as one to four workstations. Or, one 
to four HASP hosts or HASP compatible workstations may 
each regard the Xerox Satellite Processor as a single work- 
station. Any combination thereof concurrent with a single 
spooled playback operation is also allowed. 



COC HANDLER 

The character-oriented communications (COC) handler pro- 
vides communication between real-time programs and 
various terminal devices. The COC hardware consists of 
a controller and from one to eight transmission-line inter- 
face units. RBM can accommodate one COC controller. 
See Chapter 4, M:COC, for a more complete discussion 
of the COC handler. 



PLOTTER SYMBIONT 

The plotter symbiont is a foreground program that drives a 
Xerox 7530 or 7531 graph plotter via a symbiont file on 
disk. The FORTRAN subroutine library provides background 
program subroutine calls for building the plotter-symblont 
command file. 



The Xerox Satellite Processor will address a data set con- 
troller exclusively In half-duplex mode in order to realize 
the increased line-driving efficiency provided by software 
command chaining. The 7605 controller is used by Xerox 
Satellite Processor in either two-wire or four-wire mode. 
Line speeds supported are 2000 - 19,200 bits per second. 



BSS 

A low overhead Basic Spooling System Is provided for RBM. 
The Basic Spooling System is intended to provide minimum 
core resident support for RBM users. Basic Spooling System 
functions are as follows: 

• Spxjols to circular direct access disk file. 

• Unspools to a physical or logical device. 

• Operator may start, stop, suspend, skip, or backspace. 
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• Overflow threshold alerts operator when critical low 
available space conditions occur. 

• Core resident control information is periodically check - 
pointed to disk resident information table to prevent 
loss of data. 

• If any record with the charocters *FORMSin column 1 
through 6 is detected, the *FORMS record is diverted 
to the Operator's Console ond on outomatic STOP 
occurs. 



RBM TERMS AND PROCESSES 

The following items are either unique to the RBM system or 
have specific meaning within the RBM context. Other 
terms and processes not defined below are explained in an 
appropriate chapter. 



TASK 

A "task" is an entire set of foreground operations performed 
independently of other tasks in the system. It must be 
connected to one and only one hardware interrupt. A task 
may use Monitor service routines but must never branch to 
another task. One task may trigger the interrupt level of 
another task by means of a Write Direct instruction. The 
prescribed entrance and exit procedure for all real-time 
tasks in the system is described in Chapter 6. 

A task logically consists of three parts (that may or may not 
be contiguous in core storage): 



• Monitor Control Panel interrupt routine. 

• Monitor machine fault and protection violation routines. 

• RBM control routine (for loading, abort, etc.). 

A background program con also operote as a single task but 
without foreground privileges. 

PROGRAM 

A "program" is one or more tasks {and optionally, some 
data storage) that are looded and controlled as a unit. Four 
types of programs exist under RBM: 

T. Resident foreground programs consisting of one or more 
tasks, perhaps some special routines for receiving I/O 
interrupt responses (see "End Action"), and any com- 
mon storage that may be needed. 

2. Semiresident foreground programs that are explicitly 
called in from secondary memory and reside in the 
resident portion of core memory during execution. 

3. Nonresident foreground programs. 

4. Background programs, consisting of a single task. 

FOREGROUND 

"Foreground" refers to real-time or Monitor tasks executed 
in protected memory on a real-time basis. Since the num- 
ber of foreground tasks is limited by the number of in- 
ternal and external interrupts available In the r^ystem, the 
fundamental limitation is the amount of core space avail- 
able. However, the use of overlays and nonresident fore- 
ground programs mokes the amount of effective foreground 
space virtually unlimited, depending only on the severity 
level of required response times. 



1. A Task Control Block (TCB) that contains status Infor- 
mation ond the contents of the registers from the Inter- 
rupted task (see Table 18). The TCB Is normally the 
first loadable item in the object module. 

2. A task body, consisting of a sequence of instructions 
executed in response to the tosk interrupt. 

3. A task temporary storage area for use by the Monitor 
service routines (and other reentrant library routines) 
to provide reentrancy for these routines. 



BACKGROUND 

"Background" refers to a non-real-time program executed 
In available nonprotected memory. The purpose of back- 
ground programming is to achieve higher efficiency in the 
system by using the CPU time not needed by real-time tasks 
to maintain foreground programs, or to perform other data 
processing functions. 

Background operations may be assemblies, compilations, 
data processing, or utility operations. The two fundamental 
restrictions in using background programming are 



Examples of foreground tasks are 



• Real-time foreground tasks connected to external 
interrupts. 



Monitor I/O interrupt routine. 



1. A background program Is never allowed to interfere 
with real-time foreground tasks, it must operate in 
nonprotected memory and use the Monitor service 
routines for all I/O and other privileged operations. 

2. Since a background program uses only the CPU time 
available after the real-time foreground is satisfied, it 
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may not be guaranteed any CPU time when foreground 
is very active. The background cannot inhibit inter- 
rupts or do anything else that might interfere v/ith real- 
time foreground responsiveness. 



JOB 



A "job" is defined as consisting of all background activities 
or processes that take place between a !JOB command and 
the next {JOB command or a !FIN command (whichever 
is encountered first). 



like a hardware accumulator, i.e., to build up a cumulative 
result from single-precision or double-precision real 
(floating-point) calculations. 

As a convenience in referencing the floating accumulator, 
core locations 1 through 5 are set with pointers to the actual 
core locations. This is done when entry is made to the ac- 
tive task (by M;SAVE when the routine is used). Therefore, 
indirect addressing through locations 1 through 5 will result 
in storing, loading, or modifying the actual floating accu- 
mulator. The sixth cell of the floating accumulator is used 
by the FORTRAN -formatted I/O routine. 



JOB STEP 

A "job step" is defined as the operations performed insetting 
up and processing a single program within a job stack. A 
job step is initiated by calling in a background processor 
and ends when the processor exits. 



MONITOR SERVICE ROUTINES 

REM service routines can be used by real-time foreground 
tasks, a background task, or RBM tasks. All routines are 
coded In a reentrant manner, and those that require tempo- 
rary storage use the temporary stack space associated with 
the task that calls the routine (see Chapter 4). 



RBM CONTROL TASK 

The RBM Control Task encompasses a number of subtasks 
that control the reading of control commands, loading back- 
ground programs, interpreting unsolicited key-ins, and 
aborting or terminating a background job. During system 
initlolizotion, the RBM Control Tosk must be ossigned to the 
lowest priority hardware Interrupt. 

The RBM Control Task uses the same entrance and exit pro- 
cedure and the same type of TCB as a real-time foreground 
task. Since its main function is to control background 
activity, it has a lower priority than any real-time task. 
It is necessary that this be a separate task (and not part of 
the background priority level) so that effective and respon- 
sive control can be made through key-ins. All RBM func- 
tions associated with this level operate as subtasks to the 
RBM Control Task and are non-reentrant. 



TEMPORARY STACK 



NONRESIDENT FOREGROUND 



The temporary stack (temp stack) is a block of core storage 
associated with a particular task and is used by Monitor ser- 
vice routines for temporary storage to achieve reentrancy. 
An entry in the TCB for a task points to the temp stack 
space. When a task is active and using either Monitor ser- 
vice routines or the floating accumulator (defined below), 
the beginning of the temp stack space for the active task 
must be set into core memory location 6 (after the previous 
contents of location 6 are saved). Monitor service routine 
MrSAVE will set this pointer. 

When Monitor service routines or Public Library routines 
need temporary space, they can call M:RES to reserve space, 
and M:POP must then be called to release the space when it 
Is no longer needed. Thus, the total temp stack Is a func- 
tion of the deepest nesting of calls to Public Library routines 
and RBM service routines and of the space required for 
these routines. 



FLOATING ACCUMULATOR 

This software convention Is used extensively by mathematics 
library routines and can also be used by any user's program. 
The floating-point accumulator is assumed to occupy the 
first six locations of the temporary stack space. It is used 



Nonresident foreground programs ore real-time progroms 
not needed in core on o continuous basis. They are created 
like resident foreground programs and are then written on 
the RAD in the user processor (UP) area. An operator or a 
resident real-time program can later call one of these non- 
resident programs, and it will be loaded and executed like 
a permanently resident real-time foreground program with 
all the protection and priority privilege characteristics of 
the foreground. 



COMPRESSED RAD FILES 

EBCDIC character codes do not use all possible bit combi- 
nations of an eight-bit byte, and some combinations (X'DC 
and X'EC) are therefore available for special coding bytes. 
Since EBCDIC information often contains a large number 
of "blank" byte strings, a code and a v*/ord count are used 
to replace an entire string of blanks. Thus, several 80-byte 
source cards (usually about 12) can be compressed and 
blocked into a 360-byte RAD sector. The RBM Read and 
Write routines provide the compression or decompression 
feature, and the user program can read or write as though 
the file contained 80-byte card images. Compressed files 
are always blocked; that is, several records are transferred 
with one RAD access. 



RBM Terms and Processes 



2. CONTROL COMMANDS 



The Monitor is controlled and directed by control commands 
that initiate loading and execution of programs and provide 
communication between a program and its environment. 
The environment includes the Monitor, background proces- 
sors, the operator, and peripheral equipment. 

Control commands hove the genera! form: 

X 



! mnemonic specification 



whf 



! is the first character of the record and identifies 

the beginning of a control message. 

mnemonic is the mnemonic code name of a control 

function or the name of a processor. It must 
imrnediately follow the ! character without inter- 
vening spaces. 

specification is a listing of required or optional 

specifications. This may include labels and nu- 
meric values appropriate to the specific command. 
In the specification field, hexadecimal values 
must be shown as +xxxx and EBCDIC values must 
begin with a letter; any other values are assumed 
to be decimal values. Specification fields are 
separated by a comma or an equals sign. 

In this manual the options that may be included in the 
specification field of a given type of control command are 
shown enclosed in brackets although brackets are not used 
in actual control command format. 

One or more blanks separate the mnemonic and specifica- 
tion fields, but no blanks may be embedded within a field. 
A control command is terminated by the first blank after 
the specification field. Annotationol comments detailing 
the specific purpose of a command record may be written 
following the specification terminator, but not beyond col- 
umn 72. Only columns 1-4 are examined to determine con- 
trol functions; only the first eight nonblank characters fol- 
lowing the I are used to locate processors. 

The user may insert comment lines within a job stack at any 
point where a Monitor control command would be recognized, 
A comment line contains an asterisk as the first character of 
the line. The comment line is listed on the LL device. 

Communication between the operator and the Monitor 
is accomplished via control commands, key-ins, and 
messages. Control commands are usually input to the 
Monitor via punched cards; however, any input device(s) 
may be designated for this function (see ! ASSIGN com- 
mand). Control key-ins are always input through the 
keyboard/printer. All control commands and Monitor 
messages are listed on the output device designated as 



the listing log (normally a line printer) to provide a 
hard- copy history of a Job. 



JOB CONTROL PROCESSOR (J€P| 

Monitor control commands are read from the background 
operational label CC unless the operator has requested a 
keyboard/printer override through an unsolicited KP key-in. 
All such commands are read by the Job Control Processor 
(JCP), a special processor loaded into the background by the 
RBM and reloaded into the background following each 
job step within a job. When a control commar>d is en- 
countered by the JCP, the order of search is 

1 . Monitor control commands. 

2. System processor names. 

3. User processor names. 

4. Foreground processor names. 

5. Background processor names. 

A IJOB command sets all background operational labels to 
their standard assignments. All temporary RAD space is set 
"unused" and is then available for following job steps. 

As the JCP encounters ! ASSIGN and (DEFINE commands 
between job steps, it makes appropriate entries in the oper- 
ational label tables and continues to do so until it encoun- 
ters a request for a processor. When the requested processor 
is read into the background and attains control, this marks 
the beginning of a job step. 

At the end of each job step (i.e. , when the JCP begins 
reading control commands at the completion of the previous 
job step), all background operational labels associated 
with temporary RAD space are set to an undefined status 
and all temporary background space is reset to an "unused" 
status unless a I TEMP S control command is in effect, which 
saves temporary files until a jTEMP R, IJOB, or I FIN com- 
mand Is encountered. 



MONITOR CONTROL COMMANDS 

A6S The lABS control command causes the Absolute 

Loader to read absolute binary programs from the AI device 
and write core image copies onto the OV file. The last 
(or only) segment to be read must be followed by an lEOD 
command. The binary program(s) following the !ABS com- 
mand must contain only those load items that are port of the 
standard absolute object language. The program can be 
a background program, a processor for the background, or 
a real-time foreground program. 

A subsequent I XEQ command causes the RBMsubtosk SrLOAD 
to load the core image of the root segment (segment number 0) 
from OV into core storage. Subsequent segments (I - n) 
are loaded by the root through the use of MrSEGLD. 
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When an jABS control command is encountered, the 
Absolute Loader reads the absolute deck that follows (ter- 
minated by an !EOD) from the Al device and writes the core 
image copy onto the file to which the OV operational label 
is currently assigned. If OV has not been assigned, it will be 
assigned by default to the RBMOV file on the RAD. The 
program can be executed from a permanent SP (system pro- 
cessor) or UP (user processor) file either by inputting a 
"!name" command (where "name" is the name of the file on 
which the program was written), or an !XEQ command. 

If a multisegment program is loaded, the Absolute Loader 
creates an OVrLOAD table at the end of the root. The root 
must always be the first load module and each succeeding 
load module Is assigned a consecutive segment identifica- 
tion number, with the first succeeding segment starting 
at "1". In the OV:LOAD table, each segment's load ad- 
dress will be at its origin location and its entry address will 
be the transfer address generated by the END card image. 

The form of the !ABS control command is 

lABS [size][,oplb.][,oplb ]. ..[,oplb] 



where 



labels for the background are reset to the standard values 
at the beginning of a job by the Job Control Processor, an 
operational label assignment is in effect only until the next 
!JOB command is encountered or until it is again reassigned. 

An operational label is a two- character name that is used 
as a label in referring to a device-file number. The con- 
vention of operational labels is used for the processors or 
any other program to make them device-independent, and 
also to give some mnemonic value to the input/output opera- 
tions associated with the processors. 

Device-file numbers are a logical means of referring both 
to a physical peripheral device and to a collection of in- 
formation about that device; that is, the current file of 
information. Device file numbers are defined sequentially 
in the DEVICE FILE INFO parameter during SYSGEN. 



Standard operational labels can be reassigned to different 
device-file numbers during SYSGEN or through {ASSIGN 
and [DEFINE control commands. Two tables of operational 
labels are maintained by the system; one is used for back- 
ground (see Table 2) and the other for foreground. Device 
unit numbers (see Table 3) are also stored in the same two 
tables in the form of binary integer values. 



size Is an optional parameter for background pro- 

grams only. It specifies the temp stack size 
required for the background program being 
loaded. If size is omitted, a temp stack size 
equal to the maximum size needed for all Monitor 
service routines (80) will be used. The temp stack 
will always be allocated at the start of back- 
ground, and It is the user's responsibility to origin 
his program above the temp stack. For foreground 
programs, the size parameter is ignored and the 
temp stack pointers must be assembled as part of 
the program (I.e., In the TCB). 

oplb-j ,oplb2 . . . ore operational labels used by the 

program that requires blocking buffers (I.e. , those 
labels that may be assigned to blocked RAD files). 
A maximum of 10 operational labels may be speci- 
fied. When the program is loaded from the RAD 
for execution, the Monitor will ensure that enough 
blocking buffers are available for these specified 
labels assigned to blocked files. 

Programs loaded under the Absolute Loader are subject to 
the following restrictions: 

• No external references are permitted. 

• The program must be In absolute form. 

• Relocatable code may not be imbedded. 



ASSIGN The lASSIGN control command causes either a 

new or standard operational label to be equated with a 
specified (or temporary) file number. Since operational 



Table 2. 


Standard Background Operational Labels 


Operational 


Explanation 




Label 


of Reference 


I/O Device 


AI 


ABS binary input 


CR,PT,MT,RD 


BI 


Binary input 


CR,PT,MT,RD 


BO 


Binary output 


CP,PT,MT,RD 


CC 


Control command 


KP,CR,PT,MT, 




input 


RD 


DO 


Diagnostic output 


Same as LO 


GO^ 


Execution input (GO) 


CR,MT,PT,RD 


ID^ 


Debug ident file 


RD 


LI 


Library input 


Same as BI 


LL 


Listing log 


Same as LO 


LO 


Listing output 


LP,KP,MT,RD 


OC 


Operator's console 


KP 


OV^ 


Overlay (temporary) 


RD 


Pl" 


Processor input 


RD 
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Table 2. Standard Background OperaHonal 
Labels (cont.) 



The foreground operational labels reserved for use by RBM 
are as follows: 



Operationol 
Label 


Explanation 
of Reference 


I/O Device 


SI 


Symbolic input 


KP,CR,PT,MT, 
RD 


S2* 


Sigma ^3 procedures 


RD 


UI 


Update Input 


CR,PT,MT,RD 


uo 


Update output 


PT,MT,RD 


XT*** 


Overlay Looder, 
ExterKJed Symbol 


MT,CR,RD 


X2*** 


Overlay Loader, 
Extended Symbol 


RD 


X3*** 


Extended Symbol 


RD 


X4 


Utility (verify) 


RD,MT,CR,PT 


X5*** 


Utility (prestore) 


RD 


These operational labels, if required by a processor, 
are automat J call y assigned to permanent files in the 
system data area by the Job Control Processor. 


The PI operational label is assigned to files in the 
System Processor and User Processor areas by the Job 
Control Processor. 


These operational labels are automatically assigned 
to background temporary RAD files, with the file defi- 
nition appropriote to the background processor being 
executed. These definitions are made from a table in 
the Job Control Processor that is selected by the first 


three characters of the processor name. 



Label 



Usage 



AL 


Accounting log 


CK 


Background checkpoint 


DP 


Mount/remove key-ins 


EF 


Error log 


ML 


Program loading 


RM 


Overlay input 



Device 



RD 



An assignment to file zero means that the operational label 
Is not effective, and all references to this operational label 
result in a no-operation until it Is reassigned. Note that some 
background processors (e.g. , Utility ) do not allow use of 
active operatiorxjl labels assigned to file zero. See Appen- 
dix B for a complete description of operational label usage. 

{ASSIGN commands can appear anywhere within the con- 
trol command stack (except within a job step) and take ef- 
fect immediately. That is, if the CC operational label is 
reassigned, the very next control command is read from the 
newly assigned device (unless the KP override has been im- 
posed by an unsolicited key-in). The ! ASSIGN command 
Is used for both foreground and background operational labels. 
(The operator must key in FG before assigning a foreground 
operational label. ) 

There are four forms of the {ASSIGN command. Form 1 Is 
'ASSIGN oplb^evice-file-number[,F][,(optI)][,(opt2)] 



opib is either a two-character alphanumeric name 

in the foreground or background operational label 
table (or is to be placed In the table), or a FOR- 
TRAN device unit number, indicated by the pre- 
fix F: preceding the device unit number (see 
Table 3). 



Table 3. Standard Device Unit Numbers 



Device Unit 




Number 


Standard Assignment 


101 


Keyboard/printer input 


102 


Keyboard/printer output 


103 


Paper tape reader 


104 


Paper tape punch 


105 


Cord reader 


106 


Card punch 


108 


Line printer 



device-file-number 
range I to 50. 



is a decimal integer in the 



F when present, declares that the assignment is to 
be included in the foreground operational label 
table. Otherwise, it Is assumed to be In the back- 
ground operational label table, and the file num- 
ber must also be a backgrourwd file number. 

opt 1 and opt 2 are device specific options which 

may be one to four characters. If more than four 
characters are specified, only the first four will 
be used. Note that the device specific options 
are meaningful only for certain devices. Use of 
an unrecognized option for a device results in an 
error return of INVALID OPTION. 
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The following opHons are recognized for 
Model 3325/33 tape drives: 



800 



for 800BPI; NRZI recording 



1600 for 1600BPI; phase encoded 

recording 

ASClQ] for ASCII code conversion 

EBCDQc] EBCDIC data (ASCII code con- 
version "off") 

Form 2 of the lASSIGN command is 

/ 'ASSIGN oplb=filename,area[,F][,S] 



whe 



opib is an operational label or a device unit num- 

ber identified by the F: prefix, 

filename is the name of an existing RAD file. The 

RAD file is rewound if itisblocked or compressed. 

Only permanent RAD files can have a filename. 
Once the filename is entered in the dictionary 
by SYSGEN or RAD Editor, an lASSIGN control 
command or call to M:ASSIGN can equate either 
an operational label or FORTRAN device unit 
number in this filename, 

area specifies the area to search for the filename 

from the areas listed in Table 1, 

F indicates that the assignment is to be included 

in the foreground operational label table. 

S indicates that this file (if packed format) may 

use the sharable blocking buffer if provided by 
the Task Control Block. 



F and S are not order dependent. 



Form 3 of the lASSIGN command is 
/lASSIGNoplb=^plb[,F]C(opt1)][,(opt2)] 



where 



op 



lb 



is as defined above. 



F if present, indicates that both operational labels 

are foreground; otherwise, both operational labels 
must be background labels, 

optl and opt2 are as defined for form 1. 



Form 4 of the jASSIGN command is 
X {ASSIGN opIb = area,area[, F] 



where 

opIb is as defined above. 

area identifies the disk area to which the opIb is 

to be assigned (must be specified twice). 

F if present, indicates that the operational label is 

for the foreground; otherwise, it is assumed to be 
a background label. 

This form of the ASSIGN command allows access to on area 
as if it were a file with the following characteristics: 

Format: random 

Logical record size: sector size in bytes 

Write protection: area write-protect code 

BOT: BOT of area 

EOF: none 

EOT: EOT of area 



Examples: 
Form 1 : 

Form 2: 
Form 3: 
Form 4: 



lASSIGN SI = 3 
lASSIGN F:105 = 3 

lASSIGN OV = ROOT,UP 

lASSIGN LI= BI 

lASSIGN SI=CP,CP 



ATTEND The lATTEND control command indicates that 

RBM is to go into a wait condition on any abort from the 
background, and then read and process the next control com- 
mand encountered when background processing continues 
after an unsolicited key-in. Its primary purpose is to offer 
improved recovery procedures. If an abort occurs without 
this control command being specified, JCP will reset the 
CC operational label to the standard value, skip all con- 
trol commands, binary records, or data until it finds a 
new I JOB, I PURGE or I FIN command, and will not pause 
for operator intervention. In this "skip" mode, all EBCDIC 
records beginning with ! will be listed on the LL device, 
with an indication ('>' preceding the command) that they 
are ignored. This is the normal mode for closed-shop batch 
processing, without halts between jobs after aborts. 
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The form of the command is 



[ATTEND 



It exists for one fob only, and usually immediately follows 
the !JOB command. 

C« The IG: control command connects the designated 

real-time foreground task to a specified interrupt location, 
optronally armed and enabled as specified by the control 
code- The task may also be triggered by means of this con- 
nect operation if the code is equal to seven, providing that 
the task has previously been armed (i.e., with a previous 
!C: command, an IXEQ or "Iname" command, or by a 
Q key-in) - 



The form of the !C: control command Is 



tcb[, codej 



tcb is the address of the Task Control Block for 

this task. If the value is hexadecimal, it must be 
shown as -bcxxx. If the Overlay Loader initializes 
the TCB by means of the TCB parameters, it does 
so completely, using load information and values 
on the TCB and BLOCK cards. No partial initiali- 
zation of a TCB is allowed with the exception of 
the blocking buffer pool. If a user builds his own 
TCB, the TCB must begin at the execution location 
plus the "temp" value specified on the Overlay 
Loader !$ROOT command, 

code when present, is the interrupt operation code. 

It overrides the initial TCB task code; a code of • 
7 triggers the task if it is armed. 

Note: If "code" is not specified, the code given 
in the TCB will be used. 

The !C: command does not change the contents of the TCB. 

CC The ICC control command returns control to the cur- 

rently assigned CC device and nullifies the effect of a 
previous KP key-in. The control command is honored 
regardless of whether or not the "skip" mode is in effect. 
The "skip" mode is cleared following this command. The 
form of the command is 



!CC 



DEFIKE The ! DEFINE control command allocates a 

portion of the background temporary RAD space for a spe- 
cific operational label or device unit number by assigning 



the operational label to an unused device-file number, 
which in turn is linked to the specified portion of the RAD. 
Since temporary RAD files are not maintained by the Moni- 
tor, they have no name and are identifiable only by the 
operational label for which each file was created. The 
I DEFINE control command must precede the specific pro- 
cessor or user program to which It applies, since this tem- 
porary space Is reset at the beginning of each Job and at 
the subsequent reloading of the JCP (unless a ITEMP S 
control command is in effect). That is, the files are de- 
stroyed and the RAD space and all device-file numbers 
linked to It may be used by the next job. 

The form of the 'DEFINE control command is 



•DEFINE oi 



plbp-P^l 
|_, nrecj 



, srec 



f R ] 


U 


, c 


B 


lIpmJJ 



opib Is an operational label or a FORTRAN device 
unit number (with a prefix of F:). 

nrec is the number of logical records in the file. 

. per Ir>dlcates the percentage of remaining back- 

ground temporary space to be allocated for this 
opIb. 

srec Is the logical record size. In bytes. 

R defines the file as an unblocked random-occess 
file. 

U defines the file as an unblocked file. 

C defines the file as a compressed EBCDIC file. 

B defines the file as a blocked sequential file. 

P defines the file as a blocked random-access file. 

S flags the desire to use a shared blocking buffer if 

provided with the program task. It Is meaningful 
only for packed (blocked random) files. 

If neither R, P, U, B, nor C is specified, the file Is defined 
as a blocked file (B). If R Is Input, srec Is used as the 
granule size. 



EOD Sections of data may be defined in a user's deck 

by inserting !EOD control commands at the end of each sec- 
tion. When an lEOD command is encountered, the Monitor 
returns an EOD status (when using the M:READ I/O routine). 
This is similar to a tape-mark on magnetic tape. Any num- 
ber of !EOD control commands may be used in a job wher- 
ever required by the user or by a processor. 



The form of the !EOD control command is 
/lEOD 
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Monitor Control Commands 



FIN The !FIN control command specifies the end of a 

stack of jobs. When the !FIN control command is encoun- 
tered, the Monitor writes it on the listing log to inform the 
operator that all current jobs have been completed and also 
writes !! BEGIN IDLE on the OC device. The Monitor then 
enters the idle state. 



The form of the !F1N control command is 



!FIN 



HEX The !HEX control command (SYSGEN optional) 

may be used to patch either the Monitor itself or any fore- 
ground program. 

The form of the !H£X control command is 

X !HEX 



The format of the patch record is described in Chapter 1 1 
under "System Patching". 



FSKIP,FBACK,RSKIP,RBACK The file positioning con- 

trol commands^ IFSKIPand IFBACK, forward or backspace 
the specified device (magnetic tape or RAD file) immedi- 
ately past the next file mark, or past the nth file mark if 
n files ore specified (n = 1 for RAD files). IRSKIP and 
IRBACK perform similar functions but act on records rather 
than files. IRBACK and IRSKIP do not apply to compressed 
RAD files. 



The forms of the control command are 



IFSKIP 
IFBACK 
IRSKIP 
IRBACK 



device [,number][,F] 



/here 



device specifies the device to be positioned and 

is one of the following: 



1. A device-file number, shown as a decimal 
integer. 



2. A FORTRAN device unit number, shown as 

F:n 

where n is a decimal integer equal to the de- 
vice unit number. 



3. An operational label, shown as two alpha- 
numeric bytes, the first of which isalphabetic. 

number is the number of operations to be performed; 

if absent, one operation is assumed. 

F indicates a foreground device/file. This indica- 

tion is not required if a device-file number (DFN) 
is specified directly. Operations on a foreground 
device or file require that an FG key-in be in 
effect. 



JOB The !JOB control command signals the beginning 

of a new job. The background operational labels and 
FORTRAN device unit numbers are set to their default as- 
signments. All RAD temp files are closed. 

This command always causes a page to be ejected on the 
LL device before the command is listed. The version of the 
RBM being utilized will be inserted following the last field 
on the jJOB command. 

The form of the IJOB control command is 

/ IJOB [name, account] 



where 

name has a limit of 12 characters, 

account has a limit of six characters. 



JOBC The IJOBC control command indicates a con- 

tinuation of the current job. IJOBC closes all RAD temp 
files and resets all background operational labels to their 
default assignments (with the exception of "CC"). The 
IJOBC command does not clear the "attend" flag or the 
"skip" mode, nor does it terminate the effect of an FG or 
SY key-in. (A useful application of the IJOBC command 
is given in the Utility job deck example in Chapter 10.) 



The form of the IJOBC control command is 

A. 



JOBC 



LIMIT The ILIMIT control command (SYSGEN optional) 

is used to set a maximum on the execution time of a back- 
ground program. This command is effective only if the job 
accounting option has been selected at SYSGEN. If the 
job exceeds the time limit, the job is aborted (TL) and is 
terminated with a postmortem dump (if that option was 
specified). 
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The form of the F LIMIT controt command is 



ILIMIf [n] 



where N is the mctximum oltowable execution time in min- 
utes (0 < N < 600). 

RE^ASE The {MESSAGE control commond is used to 

type a message to the operator. It is usefuf for messoges 
concerning mounting topes or setting certoin device or 
Control Panel conditions. The commorKf is fisted on the 
OC device. There is no response. 

The foFitJ of the .'MESSAGE controf command is 

A. 



{MESSAGE message 



where message Fs any comment to the operator, up to the 
ful I-card imoge size (total of 72 cofumns per cord). 



PAUSE The {PAUSE control command temporarily sus- 

pends background operation to olfow the operotor time to 
complete the job setup. Bockground operotions resume when 
the operator performs an unsolicited S key-in. The command 
is listed on the OC device. 

The form of the ! PAUSE control command is 

X ! PAUSE message 



where message is a comment to the operator, up to the full- 
cord image (totol of 72 columns per card). 



PMD The ! PMD (postmortem dump) command causes the 

Monitor to dump the registers, plus selected areos of mem- 
ory, at the end of a job step. The dumps are always onto 
the background DO device in specified format. The I PMD 
comrAand is only effective for one job step. 



The form of the • PMD command is 

/{ PMD [u][,ALL[,formafI]['fwa,lwa[, fonnatjj 



D 



. . . L,fwa,lwaL,formatJJ 



U indicates that PMD is to be entered regardless of 

the manner of bockground termination. Otherwise 
PMD is entered only if background terminates 
abnormolly. 



ALL indicotes that oil of background is to be 

dumped. If ALL is not specified and no other 
limits are specified, only the CPU registers ore 
dumped. 

fwa, Iwo specifies the dump startir^g Kir^ ending 
locations. These values are hexadecimal if pre- 
ceded with a plus (+) character. 

formot specifies the dump format as fol lows: 

H Hexodecimol (default, if format 

unspecified) 



M 


Mnemonic 


I 


Integer 


E 


EBCDIC 



When a format of E is specified, each dump line 
will consist of hexadecimal values followed by 
EBCDIC tronslotions, at the end of the line. Four 
limit pairs (fwa, Iwa) may be specified. The 
CPU registers are olways dumped, regardless 
of the limits. 

An X (abort) key-in will terminote oil postmortem dumps if 
performed while PMD is active. 

PURGE The I PURG E control command (SYSG E N optional ) 

is used to output the contents of either the fob accounting 
file or error-log file, and optionally to reset (i.e., clear) 
the respective file. By use of the reset option and an os- 
signment of the appropriate background operational label 
(see below) to a "hard copy" device (card punch, paper 
tape, or magnetic tape) a periodic off-line copy of the 
chosen file can be obtoined and the corresponding RAD/ 
disk space freed for further entries. (Operator messages 
will indicate the need for such oction; in the error log cose, 
a prompt response is necessary in order to prevent loss of 
records in this file. ) 

A {PURGE command will always be acknowledged whether 
in "skip" or "attend" mode. 

The form of the {PURGE control commond is 



I PURGE 



m^n 



rher 



AL specifies the job accounting file (default). 

EL specifies the error log, 

R specifies that the indicated file is to be reset 
(i.e., cleared). 

If neither AL nor EL is specified, AL is assumed. If R is 
specified, use of the command must be preceded by an 
(unsolicited) SY operotor's key-in. 
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Accounting File Output. The contents of the accounting 
file are output, via background operational label LO, in 
the following format: 

mm/dd/yy hhmm name account mmmm. mm 

where mmmm. mm indicates job execution time to the nearest 
hundredth of a minute, e.g., 0003. 85 minutes. 

Error Log Output. The contents of the error log fi le are 
output via background operational labels DO and LO. The 
output via DO is an exact restorable copy of the error log, 
record by record, followed by two !EOD records. The 
output via LO is a readable representation of each record. 
If DO and LO are both assigned to the same device, the 
DO form of output is suppressed, i.e., LO predominates. 
If DO output is to be assigned to a magnetic tape contain- 
ing previous log output, the recommended procedure is 

!JOB 

'PAUSE KEYIN SY, S 

lASSIGN DO = MT 

IFSKIP DO 

IFBACK DO 

! PURGE EL,R 

! UNLOAD DO 

!FIN 

REL Relocatable binary program modules to be loaded 
onto the GO file are preceded by an !REL control command 
The binary modules that follow must be in Xerox 16-bit 
Standard Object Language (see RBM/System Technical Man- 
ual 90 11 53). The modules may constitute a complete pro- 
gram, a root, or segments of a program. Checksum and se- 
quence checks will be performed. 

The form of the !REL control command is 

A 



!REL 



The modules are copied onto the file to which GO is cur- 
rently assigned. If GO has not been assigned, it will be 
assigned by defau^t to the RBMGO file on the RAD, which 
is rewound before the modules are copied. Several modules 
may be copied through the use of one iREL control command 
by stacking the modules. The final module must be fol- 
lowed by an !EOD control command that will cause the 
JCP to write an end-of-file (EOF) onto GO and then 
backspace one file. In this manner the GO file is 
positioned to accept additional input, but is always 
terminated by an EOF. The relocatable binary decks are 
loaded from operational label BI. 

The !REL control command is a convenient method of 
obtaining additional hard copies of object modules pro- 
duced on GO by Extended Symbol or FORTRAN. By 
assigning BI to GO and then reassigning GO to BO, modules 
will be copied from the original GO onto BO up to and in- 
cluding the EOF. BI should be rewound before each IREL 
command. 



REWIND The {REWIND control command rewinds a mag- 

netic tape or a RAD file and has no effect on other devices. 
The operation takes place immediately after the command 
is interpreted. 

The form of the IREWIND control command is 

/iREWIND device[,F] 



where 

device specifies (as in !FS KIP) the device to be re- 

wound, by opiabel, fdun (FORTRAN device unit 
number), or DFN . 

F indicates a foreground device/file. This indica- 

tion is not required if a device-file number (DFN) 
is specified directly. Operations on a foreground 
device or file require that an FG key-in be in 
effect, 

TEMP Normally, the temporary background space on 

the RAD is reset at the completion of each step within a 
fob, so that a separate assembly and compilation can each 
have full access to this temporary area for scratch space 
as needed. The ITEMP control command is a means of 
altering this standard procedure. When used with the 
save (S) option, temporary files are not released after any 
job step within a job stack until either a ITEMP command 
is encountered with a reset (R) option or the next !JOB, 
!JOBC,or !FIN command is encountered. 

The form of the ITEMP control command is 



ITEMP 



fS 

R 
iTi 



where either S or R is required 

S means to save RAD temporary files between job 

steps within a job (e.g., between an assembly 
and a concordance). 

R means to reset the RAD temp files after each job 

step. 

T means truncate the previous file so that it will 

only be as long as the end-of-file. If no EOF has 
been written the shortened file will be one record 
long. Space recovered in this fashion can be 
reallocated by subsequent use of the {DEFINE 
command. 



UNLOAD The lUNLOAD control command causes a 

specified magnetic tape or RAD file to be rewound in man- 
ual mode. Operator intervention is required to use the de- 
vice again. If the device Is a RAD file, the file is rewound 
to BOT and released by a call to M:CLOSE. 
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The form of the 'UNLOAD control command is 

A 



!UNLOADdevice[,F] 



^here 



device specifies (as in ! PS KIP) the file to be re- 

wound off-line. 

F indicates a foreground device/file. This indica- 

tion is not required if a device-file number (DFN) 
is specified directly. Operations on a foreground 
device or file require that an FG key-in be in 
effect. 

WEOF The JWEOF command writes the appropriate end- 

of-file mark on the output device. For magnetic tape, it 
is a tape mark; for the card punch or paper tape punch, it 
is an !EOD command; and for RAD files, it is a logical file 
mark. 



The form of the jWEOF control command is 



IWEOF device[,number][,F] 



^here 



device specifies (as in IFSKIP) the device that is 

to have an end-of-file written on it. 

number is the number of end-of-files to be written. 

If absent, one end-of-file is written. 

F indicates a foreground device/file. This indica- 

tion is not required if a device-file number (DFN) 
is specified directly. Operations on a foreground 
device or file require that an FG key-in be in 
effect. 

XEQ The !XEQ control command loads the root module 

from whatever file the OV operational label is currently as- 
signed to. For foreground programs, the command must be 
preceded by an FG key-in. 

The form of the !XEQ command is 



!XEQ 



XED The !XED control command performs the same 

operations as the !XEQ control command except that !XED 
transfers control to RBM Debug through the entry point 
D: KEY when the root segment has been loaded. The mes- 
sage !!DKEY-IN will appear on the keyboard/printer and 
the user can then input Debug control commands. (See 



Chapter 12 for a discussion of RBM Debug.) The I XED con- 
trol command causes the background operational label ID 
to be default-assigned to the RBMID file on the RAD if it 
is not already assigned. 

The form of the !XED control command is 

/ !XED 



PROCESSOR CONTROL COMMANDS 

Processors in the System Processor area and any user back- 
ground or foreground program residing in the User Processor, 
Foreground or Background Program areas can be called by a 
processor control command. The commands have the format 

! processor parameters 



^here 



processor is the file name of a processor that must 

be distinguishable in the first three characters from 
system control commands (see Table 4). The order 
of search (by area) is SP, UP, FP, BP. 

parameters avQ optional parameters interpreted by 

each particular processor. 



Table 4. RBM System Processors 



Name*" 


Description 


FORTRAN 

RPG 

OLOAD 

UTILITY 

XSYMBOL 

RADEDIT 

SORT 


FORTRAN IV Compiler 
Report Program Generator 
Overlay Loader Subsystem 
Utility Subsystem 
Extended Symbol Assembler 
RAD Editor Subsystem 
Sort Processor 


The RBM System Processor names are entered into 
the System Processor area dictionary with the RAD 
Editor I'^'ADD command. If the file name is less 
than eight characters, the name on the processor 
control command must exactly match the file name. 
If the file name is eight characters (maximum), the 
first eight characters of the name on the processor 
control command must exactly match the file name. 
Trailing nonblank characters beyond the eighth 
character in the processor control command name 
are ignored. 
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Processor Control Commands 



When a processor control command is read and interpreted 
by the Job Control Processor, the root segment of the speci- 
fied subsystem is loaded from the RAD into memory. The 
JCP will assign all permanent RAD files used by the speci- 
fied processor before the processor is executed unless these 
files were previously assigned via lASSIGN commands. The 
JCP will also define all temporary operational labels used 
by the processor (by defining them as background temp 
files) unless they are previously defined via [DEFINE com- 
mands. JCP then transfers control to the processor. 

When a requested processor is read into the background and 
attains control, this marks the beginning of job step. An 
example of a job stack illustrating its breakdown by job 
step is shown in Figure 2. 



EXTENDED SYMBOL CONTROL COMMAND FORMAT 

The Job Control Processor reads and interprets the 
IXSYMBOL control command and loads the Extended Sym- 
bol assembler from the RAD into background memory. The 



assembler continues to assemble programs until it encounters 
an end-of-file. The Extended Symbol assembler is called 
into operation with the command 

IXSYMBOL [option^, option., ... ,option 3 



where option can be 

BA specifies batch assembly mode. XSYMBOL will 
ignore single end-of-files and will terminate only 
when two consecuti ve end-of-f i les are encountered. 

BO specifies binary output, 

CR specifies cross-reference listing. 

DW specifies display warnings. 

GO specifies output GO file. 



Job Step 




!FIN 



lEOD 



!*REWIND UI 



l*COPY F, ALL, FORM 



!*OPLBS LO 



! UTILITY COPY 



lASSIGN LO=2 



lASSIGN UI=10 



I REWIND LO 



Job Step 




X 



lEOD 



:i 



Source Deck 




IXSYMBOL LO,CR 



I REWIND 10 



lASSIGN LO=10 



'ATTEND 



IJOB 



y 



Monitor enters 
"Idle" state. 



JCP is read into 
background 

Utility is read 
into background. 



JCP is read into 
background. 



Extended Symbol 
is read into 
background. 



Figure 2. Job Stack Example 
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LO specifies list assembly output. 

LU specifies list update. 

NP specifies no standard procedure input. 

PP specifies punch standard procedure file. 

SL specifies simple literals, 

SO specifies source output. 

SS specifies symbol summaries, 

UI specifies update input. 

Any number of options may be specified and in any order. 
If no options are specified, the following options are 
assumed by default: 

BO, GO, LO 

The presence of any nondefault option requires that any 
desired default options (except SI which is always defaulted) 
must also be present. 



FORTRAN IV CONTROL COMMAND FORMAT 

The Job Control Processor reads and interprets the 'FORTRAN 
control command and loads the FORTRAN IV compiler from 
the RAD into background memory. The compiler is called 
into operation with the command 



• FORTRAN s,,s.,...,s 
1 2 n 



where s- can be 

LO specifies an object listing. 

LL specifies an object listing with data chains. 

XP specifies extended precision real data instead 

of standard precision. 

ALL specifies that multiple files are compiled, 
FORTRAN will ignore single end-of-files and will 
terminate compilation only when two consecutive 
end-of-files are read. 

(The processor that is loaded may be either the Basic or ANS 
FORTRAN IV compiler, at the installation's option. ) 

Binary output is normally output on both the BO and GO 
devices. To suppress the BO or GO output, the user must 
assign the pertinent operational labels to (see lASSIGN 
and ! DEFINE control commands in this chapter). 

If no specifications are present, binary output on the BO 
and GO devices, a source listing, and standard precision 
mode are assumed by default. 



RBM/PROCESSOR INTERFACE 

Ground rules common to all system processors are: 

• All processors operate in the background. 

• With the exception of the UTILITY program, processors 
must use standard background operational label table 
assignments for their I/O requests. (See Table 2 for 
the standard background operational labels.) 

• The first character of each line of the listed output 
from the processors is always interpreted as a vertical 
format character (carriage control) and is never printed. 
The RBM I/O routines treat the vertical format properly 
for the keyboard/printer, line printer, and magnetic 
tape. 

• When the RBM transfers control to a background pro- 
cessor, the X register contains the address of the con- 
trol card image, providing access to any parameters. 

• At the completion of an assembly or compilation, the 
processor writes two end-of-files on the LO device, 
and then backspaces the LO device one file. The 
M:CTRL routine will treat these operations for the 
devices as described in the I/O section. This permits 
file processing of output on magnetic tape, if LO is 
assigned to magnetic tape. The processor writes an 
EOF on BO and GO at completion and then back- 
spaces one file (GO and BO are separate options). 

• The processor generally returns control to RBM by 
means of a call to M;TERM. RBM will immediately 
read from CC and if there is another control command 
for the current processor, it will reload the processor 
from the RAD. 

• If overlay loading is required, the processor uses 
M:SEGLD. The overlay operational label for the 
background is PI. 

• If an irrecoverable error occurs, the processor exits 
to RBM with a call to M:ABORT and displays the abort 
code In the X register and the abort location in the 
A register. 

• Since all standard RAD files are defined by the Job 
Control Processor, the processors need not call 
M:DEFINE, but must call M:CLOSE to release blocking 
buffers in those cases where several RAD files are used 
but are not all open at one time. 

• The first output line to LO from an assembly or com- 
pilation should contain a top-of-form format code. 



GO AND OV FILES 

Figure 3 shows how the JCP and Extended Symbol or Basic 
FORTRAN IV use the operational labels GO and OV. The 
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Figure 3. Use of GO and OV Files 



GO and OV files are the files to which these operational 
labels are assigned by the JCP and are standard default 
files when no operational labels ore specified. The GO 
file is a blocked, sequential file that contains relocat- 
able binary decks read from the job stack, and binary 
ouput produced as a result of an assembly or compila- 
tion. After each module is loaded onto the file, an 
end-of-file mark is written and a backspace file is per- 
formed. Thus, at any point within a job stack the 



GO file contains all modules that have been loaded and is 
in position to accept others. 

The Overlay Loader may now use the contents of the GO 
file to create an executable core image program and save 
this program on the random-access OV file. Absolute bin- 
ary decks produced by an assembly may also be written (in 
executable core image form) onto the OV file by JCP 
through use of the !ABS command. 
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3. OPERATOR COMMUNICATION 



SYSTEM COMMUNICATH)N 



I/O RECOVERY PROCEDURE 



When events take place in the system that require operator 
intervention, or when one job is completed and another job 
begins, RBM informs the operator of these conditions by 
messages on the keyboard/printer. All such messages from 
the Monitor begin w/ith two exclamation marks (! !)and are 
described in Table 5. 

Generally, these messages require no operator response on 
the keyboard/printer but may indicate that some peripheral 
device needs attention. In some cases, the operator must 
interrupt and key in a response after correcting the speci- 
fied problem. 



If a message concerns an l/O error condition, the Mon- 
itor I/O routines that generated the message will be wait- 
ing to sense a change of state in the device. (A change of 
state is defined as a change from manual to automatic, or 
from automatic to manual and back to automatic, depend- 
ing on the initial condition.) When the change of state is 
sensed, the operation is retried. Thus, if the device is 
EMPTY, it need only be placed in the automatic mode. 
If there is a PUNCHES error or a FAULT on the card 
reader, the reader is unloaded, the bad card is corrected 
and replaced, and the reader is returned to the automatic 
mode. 



Table 5. Monitor Messages 



Message 


Meaning 


1 JAL lO ERRORS 
IIBEGIN WAIT 


An irrecoverable l/O error has occurred while accessing the accounting file, 
normally because of a hardware failure or unavailability of operational label 
AL. The correct assignment of this operational label is to RBMAL, SD. An 
attempt should be made to recover the contents of the accounting file as 
stated above. If this recovery fails, the operator may gain control through 
a KP key-in and then an FG key-in to allow foreground modifications; the 
foreground operational label AL may then be reassigned (e.g., lASSIGN AL 
= RBMAL, SD, F or lASSIGN AL = 0,F). 

Note: Assignment of the fore.qround operational label AL to zerowill inhibit 
the logging of job stack entries into the accounting file. 


1 !AL OVERFLOW^ 
IIBEGIN WAIT 


The accounting file (RBMAL) cannot accept another entry. The accounting 
file is allocated at SYSGEN and accommodates 74 entries. (The user may 
increase or decrease this capacity via the RAD Editor.) At this point, normal 
error recovery will be a key-in of KPto gain keyboard /printer control. 
Next, a key-in of SY will permit access to the accounting file. The oper- 
ator should now assign the background operational label LO to a hardcopy 
device (e.g., paper tape, card punch). Input of a IPURGE control com- 
mand specifying the clear option (i.e., IPURGE AL,R) causes the contents 
of the accounting file to be copied onto that device and clears the account- 
ing file. The job stack causing the overflow can now be reentered. 


IIATTEND ERROR XX 


JCP has read an erroneous control command while operating In the ATTEND 
mode, in which case RBM goes into a wait state after typing this message. 
After a subsequent S key-in, RBM will process the next control command. 


IIBEGIN IDLE 


JCP has just read a ! FIN card (which completes a job stack) and background 
has gone into an idle state. Processing will resume on a new job stack fol- 
lowing an unsolicited S key-in. 


IIBEGIN WAIT 


The background has executed a WAIT request. An unsolicited S key-in will 
continue background processing. 


I !BKG CKPT 


Background has been checkpointedas a resuftofa foreground program request. 


This alarm occurs only if the RBM job accounting option has been exercised at SYSGEN. 
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Table 5. Monitor Messages (conf.) 



Message 


Meaning 


!! RELEASE, dtnn 


The specified device has been released for background use. 


!!BKG RESTART 


Background has been restarted from its point of interruption. 


! IBKGD XX ABORT, LOG yyyy 


The background fob has aborted at location yyyy for the reason specified by 
abort code xx. If the Job Control Processor initiated the abort, a detai led 
explanation will be written on the background DO device. 

If the system is operating in the "attend" mode (see lATTEND), RBM will 
perform any required postmortem dumps and then go into a wait state after 
an abort. After a subsequent S key-in, RBM will attempt to process the 
next control command from the CC device. 

If the system is not operating in the "attend" mode, RBM will not go into 
the wait state but will perform any required postmortem dumps and immed- 
iately begin reading from the CC device. All data cards and control com- 
mands will be skipped until a IJOB, JPAUSE, or iFIN card is found. Only 
a IJOB card will clear the "skip" mode. All control commands are listed 
on the LL device with an indication (> character) preceding the command 
to show that they are being ignored. 


!!JCP 


JCP has begun to read control commands. This message occurs at the be- 
ginning of a job and between steps within a |ob(e.g., when an assembly is 
completed). If CC is assigned to the keyboard/printer (as a standard as- 
signment, or after a KP key-in), the input light on the keyboard/printer 
will indicate that RBM is ready for input of a control command. 


!!CC NOT ASSIGNED 


JCP is unable to read a control command because theCC opiabel either is 
assigned to DFN or was not assigned during SYSGEN. 


!!SYSERRxx 


The Monitor has encountered some condition that will not permit further 
operation or a foreground task has generated an abort condition (see "Machine 
Fault Task" subheading in Chapter 6 and the "C" bit in Table 19). xx may 
be any one of the following: 

OP Operator-initiated system halt. 

SP The RAD device containing RBM cannot be recognized. 

ET An EIOP timeout has occurred. A system reset is necessary 
to continue. 

PE A task has generated a memory parity error. 

MF A task has generated a machine fault (probably the result of 
incorrect Direct I/O). 

PF A power failure has occurred at a time when RBM cannot 
recover. 


n.dtnn EMPTY 


The device specified is in the manual mode and may be out of paper, 
cards, or tape. 


! Idtnn ERROR [JRK xxxx] 


There has been a parity or transmission error on the device. If any auto- 
matic retries were specified, they will have been performed before this 
message is output. A CR device will indicate that an error card is in the 
output stacker. Recovery procedure is described above under "I/O Re- 
covery Procedure". If dt is RD, xxxx will be the errored track number, 
which 1s determined from the remaining byte count. 
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Table 5. Monitor Messages (cont.) 



Message 


Meaning 


Hdtnn FAULT 


Some condition on device type dt with physical device number nn (hexa- 
decimal) has caused this device to become nonoperational. The recovery 
procedure is described above (in the discussion under change of state). The 
operation is automatically retried when the device goes into the automatic 
mode; it is neither necessary nor possible for the operator to type in a 
response. 


! Idtnn PUNCHES 


An invalid punch combination has been sensed on an EBCDIC image. The 
card will be stacked in the alternate stacker (if there is one). 


! Idfnn DATA RATE 


A data rate overrun has occurred. If any automatic retries were specified, 
they will be performed after this message is output. 


! "dtnn UNRECOG 


Device type dt with device number nn (hexadecimal) is not recognized by 
the I/O routines. If the device is a magnetic tape unit, the requested 
drive may not be dialed in properly or power may be off in either the unit 
or the controller. 


! Idtnn WRT PROT 


The RAD or magnetic tape is physically write-protected. If a RAD file is 
logically write-protected, this message will not appear but appropriate 
status will be returned. 


lldil REQUEST,dtnn 


A request has been made to reserve the specified device. The operator 
should prepare the device and then reserve it through use of the FR key-in. 
dil refers to the dedicated interrupt location of the requesting task. 


lldil RESERVE, dtnn 


The specified device has been reserved for foreground use for the task whose 
dedicated interrupt location is dil. 


1 IFRGD XX ABORT, LOC yyyy TCB zzzz 


The foreground task with a TCB at location zzzz has aborted at location 
yyyy for the reason specified by abort code xx. The corresponding interrupt 
level will be disabled and if the task occupied nonresident foreground, an 
unload operation will be initiated. Background processing will continue. 
Because this message is written at the monitor priority level, only the abort 
message for one foreground task (the lower priority level task) will appear 
if two foreground tasks abort consecutively. 


IIKEYERROR[, comments] 


The monitor could not process an unsolicited key-in response. The message 
usually indicates a format error on the key-in, where comments may be one 
of the following: 

NO AR The wrong disk pock was mounted for an M key-in 
and the area could not be found. 

DEVICE One of the following conditions was detected: 

1 . This device was not defined, 

2. The device does not have removable areas. 
Applies to M and R key-ins. 

NO BTL There is no bad track fist for the device specified. 

2 lO ERR The device specified in the 'M' key-in cannot be 
correctly accessed. 
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Table 5. Monifor Messages (cont. 



Message 


Meaning 


!! KEY ERROR [,commenfs] 
(cont. ) 


2 ERRn The following error codes are defined in the 'M' 
key-in processing: 




n = 1 The expected device number parameter is 
not two characters. 




= 2 The key-in exceeds the 20 characters 




maximum. 




= 3 The field exceeds the maximum length of 
eight characters. 




= 4 During the 'all' option, an area is defined 
on another device. 




= 5 The area specified is not found on the 
device. 




= 6 The area name specified is found on an- 
other device. 




= 7 An expected area name is not two 
characters. 




= 8 Sector 2 does not contain a bad track list. 




= 9 No bod track list for this device is found 
in the system tables. 




= 10 An option other than the 'all' or area 
option is specified. 




= 11 There is no room available in the Master 
Directory for the specified area. 




IN USE If the key-in was an M (mount), the area must be 

removed. If the key-in was R (remove), files must be 
closed in the area (perhaps by an abort or unload). 




OVFLOW The Master Directory table length will not allow this 
key-in to be processed. 




DFN/OP The Device File table or Operational Label table has 
overflowed. 




lO ERR The device specified in the 'M' key-in cannot be 
correctly accessed. 




TEMP STACK The RBM Temp Stack has overflowed. 


n MESSAGE Gomments 


A ! MESSAGE control command has been read. The comments field may 
contain tape mounting or other instructions. RBM continues to read from 
the CC device after the message is typed out. 


! ! PAUSE comments 


A 1 PAUSE control cord has been read. The comments field may contain 
tape mounting information or other instructions. A control panel interrupt 
followed by an S key-in will cause RBM to continue reading from the job 
stack. 
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Table 5. Monitor Messages (cont.) 



Message 


Meaning 


MNO 'RBMPMD' FILE OR DFN 


A portion of background could not be saved. The first part of background 
will be dumped as zeros. 


[IPOWERON 


The system has experienced a power failure and the power-fail-safe option 
has been Implemented. If the computer is a Sigma 2 or is a SigmaS with no 
external interrupt and no critical foreground tasks, or if the background or 
RBM Control Task was active, execution will continue; otherwise it will 
crash. If the latter case, the operator should reboot RBM from the RAD 
and restart the background. 


! !dtnn NOISE REC 


A noise record has been detected on magnetic tape and ignored. (A noise 
record is one that contains less than eight bytes and an irrecoverable parity 
error). 


\ ! Idtnn BAD TAPE 


The magnetic tape mounted on device dtnn contains a bad spot that cannot 
be skipped when writing. The operator should mount a new tape and (if 
possible) rerun the job. 


! lENTER DATE AS MM/t>DAY 


A program request was made via MrDATIME for the date specifying that 
the operator be unconditionally solicited for the date. 


HENTERTIME AS HR,MN 


A program request was made via MrDATIME for the time specifying that 
the operator be unconditionally solicited for the time of day. 


! lERRFILE OVERFLOW IMMINENT 


The Error Log is about to overflow. Log entries will soon be lost unless the 
operator performs a {PURGE EL,R operation (see the IPURGE control 
command). 


!!ERRFILE OVERFLOW, PURGE 


The Error Log has overflowed and log entries are being lost. The operator 
must perform a IPURGE EL,R as soon as possible (see the IPURGE control 
command). 



OPERATOR CONTROL 

Operator control of RBM is achieved by one of two methods: 
solicited or unsolicited. 



SOLICITED CONTROL 

Solicited control will normally be in the form of a specific 
request from a foreground or background program and should 
always be directed to the operational label OC — Operator 
Console. There is no standard format for the response to a 
solicited control. 



UNSOLICITED CONTROL 

All forms of unsolicited control are initiated when the 
operator activates the INTERRUPT switch on the Processor 
Control Panel. Unsolicited control may take one of two 
forms: 

1. An unsolicited key-in request. 

2. A forced foreground disable. 



The active foreground task will be disabled and a call will 
be made to M:EXIT if all of the following conditions are 
true; otherwise, a key-in response will be requested: 



1. The value in the data switches has changed since the 
last activation of the Control Panel Interrupt (or since 
boot). 

2. The value in the data switches matches the address of 
the dedicated interrupt location of the current task, as 
specified in word 2 of the standard Task Control Block. 
See Table 19. Note that this implies that the active 
task must call M:SAVE. 



Conditions 1 and 2, when taken together, simply mean 
that the operator must intentionally enter the appro- 
priate value in the data switches; an accidental disable 
cannot normally occur. 



3. The active foreground task (that is, the one to be 
terminated) must have a hardware priority lower than 
the Control Panel Interrupt level. 
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If a forced foreground disable is specified, a foreground 
abort message will be written; otherwise the Control Panel 
Interrupt Task sets a flag in the RBM Control Task status 
word and triggers RBM. The Control Panel Interrupt Task 
then exits. 

When the RBM Control Task becomes the highest priority 
task in the system (that is, when all real-time foreground 
tasks ore nonactive), it issues an output message 

IIKEY-IN 



and requests input (up to 20 characters) from the operator. 
Because of possible delays associated with messages to and 
from the operator, no devices used for time critical oper- 
ations should time-share an l/O channel used for operator 
communications. Each key-in must be terminated with the 
New Line code. The backspace (^ or control -X) and 
delete (EOM or control-H) codes may be used before the 
New Line is typed to correct a mistyped key-in. The anal- 
ysis and subsequent action from the unsolicited key-in is 
performed at the RBM Control Task priority level. Each 
key-in mnemonic must be followed by a space before its 
argument list. 

Specific key-in responses under RBM are: 



the TCB by means of the tcb parameters, it does 
so completely, using load information and values 
on the TCB and BLOCK cards. No partial initiali- 
zation of a TCB is allowed with the exception of 
the blocking buffer pool. If a user builds his own 
TCB, the TCB must begin at the execution loca- 
tion plus the "temp" value specified on the 
Loader l$ROOT command. 

code if present, overrides the initial code in the 

TCB for the task; a code of seven would cause the 
level to be triggered. If code is not present, it 
will be derived from the task control block. 

CC Remove the keyboard/printer override of the CC de- 

vice. The next control command will be read from the 
background operational label CC. This operator key-in is 
identical to the CC control command. 

DA nn Make available a device that was previously de- 

clared unavailable (i.e., "down"), where nn is the address 
of the device. 

DB XXXX,yyyy Dump locations xxxx to yyyy if re- 

quested; otherwise, immediately dump all of background 
memory on background device DO. This key-in can be in- 
put at any time for debugging purposes. The dump will be 
In hexadecimal. 



* comment Insert a comment. Useful for remote assist 

dialog. Note that a blank must follow the asterisk. 

BL oplb = dfn[,P] Permits change of operational label 

assignments during running of background programs. 

where 



opib is an assigned operational label or FORTRAN 

device unit number. 

dfh is a decimal number specifying a legitimate 

device file number. 

P is an optional permanent change of the default 
assignment until system reboot. 

BLoplb=oplb[,P] Alternate version of BL (Background 

Label) key- in above. 

BR[(lt]ni1 Release the specified device for the next wait- 

ing task. The characters representing the device type are 
optional but, if input, will be used to validate the request. 

C: tcb[,COde] Connect the specified real-time fore- 

ground task to the dedicated interrupt location. 

where 



DC' 



CHAN.chan 

DEV,dev 

DFN.dfn 



Display the l/O-error and 
l/O-access counters for 
either one or all channels, 
as specified by the form of 
key- in. 



chan is a one- or two-digit hexadecimal channel 

number. The limits on chan are <chan < IB. 

dev 



s a two-digit hexadecimal device address. 



dfn is a one- or two-digitdevice file number (DFN), 

in hexadecimal. 

fdun is a FORTRAN device unit number. If the 

second parameter begins with "F:" or a numeral, 
an fdun is assumed. 



op lb 

F 
B 



is a two-character operational label. 

if present, indicates that the specified oper- 
ational label or FORTRAN device unit number 

is for the foreground (F) or background (B). If not 

specified, background is assumed^ 



If no parameter is specified, all channel error and access 
counters are displayed. (All channel and device numbers 
specified must have been declared at SYSGEN time.) 



tcb is the address of the task control block for this 
task. (If the value is hexadecimal, it must be 
shown as +xxxx.) If the Overlay Loader initializes 



SYSGEN optional. 
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The format of the display message output in response to a 
DC key-in is as follows: 

CHAN cc ERRORS eeee ACCESSES aaaaaaaa 

All values are displayed in hexadecimal and reflect the 
number of errors and accesses since the last counter reset 
(see the RC key-in) or since system boot, whichever is 
more recent. 



DE 



Causes Debug (if Debug is part of the system) to 
request the input from the keyboard/printer. 

DF XXXX,yyyy Dump locations xxxx to yyyy if re- 

quested; otherwise, dump all of foreground on background 
device DO. The dump will be in hexadecimal. 

DM XXXX,yyyy Dump locations xxxx to yyyy if re- 

quested; otherwise, immediately dump all of RBM on back- 
ground device DO. The dump will be in hexadecimal. 

D[t] nim/dd[/yy[,hrmn]] Reset the calendar date within 

RBM and continue processing if the Monitor is in an idle 
or wait state. 



D[T]^mni,dd[,yy[,hr,mn]] 
key- in above. 



Alternate version of D[T](Date) 



DR^ [dn] XXXX.yyyy Perform a selective dump of the RAD 

device dn to background device DO, where xxxx and yyyy 
are the first and last sectors of the block of sectors to be 
dumped. If dn is omitted, the RAD containing the SP area 
will be dumped. If dn refers to an undefined or non-RAD 
device, an error message will be written. If a consecutive 
series of sectors are all zeros, they will be skipped unless 
the last sector of this zero series is yyyy, in which case it 
will be dumped. For example, if "DR 100,200" is keyed in, 
and sectors X'l BO' through •X'215' contain zeros, X'lOO' 
through X'lAF' and sector X'200' will be dumped. This 
key-in applies only to the 7202, 7203, and 7204 RADs. 

The RAD dump routine performs RAD Input with interrupts 
inhibited, and therefore should not be used when response 
time is critical. 

DSnil,min[,dftl] Substitute one device for another, i.e., 

change the device address associated with one or more 
device/file numbers (DFNs). This key-in Is used mainly 
for reassigning Model 7332/33 (1600 BPI) magnetic-tape 
device address when one of these units has been declared 
unavailable. In the key-in syntax, nn is the hexadecimal 
device address to be replaced by mm, and dfn (optional) is 
the single DFN for which the substitution is to be made. 



(The dfn is checked to ensure correspondence to nn prior 
to change.) If dfn is not specified, all DFNs that currently 
point to device nn will be so modified. The message 

HCHANGED DFN dfn 

will be issued for each DFN so modified, so that one or more 
can later be changed back to its original assignment. The 
specified devices (nn and/or mm) may be either available or 
unavailable when the key-in is made. The availability status 
of the mm device Is applied to all DFNs reassigned to it. 

This key-in does not apply to disk/l?AD devices, nor may 
it be used to substitute one device type for another (e.g.. 
Model 7322/^3 for Model 7332/33, or tape for printer). 

DU nn Declare a peripheral device unavailable (I.e., 

"down"), where nn is the. device address. This key-in is 
not valid for the system RAD or disk, nor for the operator's 
console. Subsequent M:READ, MrWRITE, MrCTRL, or 
MrlOEX references to the "down" device will return a 
device-unavailable status. 



_roplb[,F]1 

p|fdunf,Fl Dump the information described below for 

Ldfn J the specified file, or dump the operational 

label table only. 



/here 



opib is an operational label that indirectly speci- 

fies the desired DFN. F indicates a foreground 
operational label. 

fdun is a FORTRAN Device Unit Number (e.g., 

F:101) that indirectly specifies the desired DFN. 
F indicates a foreground fdun. 

dfn is a Device File Number (DFN). 

If no parameter is specified, only the operational label table 
will be displayed. 

When a parameter is specified, the following information 
will be output on background DO device for the desired 
DFN in addition to the operational label table. 

• Contents of the specified Device Channel Status Tables. 

• Contents of the specified File Control Tables. 

• Contents of the specified l/O Control Tables. 

If the file is a RAD file, the following additional infor- 
mation will be output: 



SYSGEN optional. 



Contents of the specified l/O Control Sub-table. 

Contents of the blocking buffer assigned to the speci- 
fied file, if one exists. 
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FG[,S] Must precede any job stack operation affecting 

the foreground or the operation will be aborted. This 
key-in is effective until the next !FIN or !JOB command 
is encountered. Since the key-in is normally input in 
response to a ! PAUSE command, the optional S key-in will 
clear the wait state. 



FL oplb = (lfn[,P] Permits foreground operational label 

assignment changes during system operation. The changes 
will be reset to SYSGEN values upon system reboot. 



opib is an assigned operational label or FORTRAN 

device unit number. 

dfn is a decimal number specifying a legal device 

file number. 

P is an optional permanent change until system 

reboot. 



FLoplb = oplb[,P] 



Alternate version of FL oplb=dfn[,P] 



FR [dtjnn Reserve the specified device for foreground 

use. The characters representing the device type are op- 
tional but, if input, will be used to validate the request. 
The device type will be required to distinguish PT40 from 
KP40, etc. 



H Input hexadecimal patch cards from background de- 

vice CC. (See Chapter 11 for the format of the patch 
cords. ) Patches to RBM or foreground must be preceded by 
an SY or FG key-in, 

KP Begin reading control commands from the keyboard/ 

printer. The key-in goes into effect immediately and stays 
in effect until a CC key-in or ICC control command is 
encountered. 



L message Enter a message into the system's error log. 

The message may consist of up to 18 characters; it will be 
truncated to that length if necessary. If error logging was 
not specified at SYSGEN, this key-in will result in a KEY 
ERROR message. 



Mlln[,[vsn][,ari,ar2,...,arn]] Mount areas "or" on 

device "dn ". The operator must mount the disk pack con- 
taining areas "ar; " on device "dn" before making this 



SYSGEN optional. 

Recognized only if a disk pack unit has been declared at 
system generation. 



key-in. Unless the area specified is Xn, the disk pack 
will be read to ensure that it contains the specified 
areas. If no areas are specified, then all areas on the 
disk pack will be added to the Master Directory in core, 
otherwise, only the areas specified will be added to the 
Master Directory. If the Master Directory already con- 
tains an entry for an area, an error message ! !KEY 
ERROR, IN USE will be output. The currently mounted 
area must be removed with an R (remove) key-in and the 
M (mount) key-in reissued. Other error messages are 
listed in Table 6. The optional vsn parameter is a 
three- to eight-character volume serial number. 

For cartridge disks which contain a bod track list (Models 
7251/52 and 3231/32/33), the M keyin will read the bad 
track list into the system tables. 

Twenty characters, including © , is the maximum that can 
be input for any one key-in. If an M key-in exceeds 20 char- 
acters, it can be divided into two parts. For example 

M dn, 67890 1 23, a 1 , a2, a3 ® 
is 23 characters long. It may be divided up as 

M dn, 67890 123, a 1 © followed by 

Mdn,a2,a3 © 

M dn,Xn[,wp] Mount area Xn on device "dn". 

where 

wp specifies the write-protection level for the area 

as denoted by one of the following codes: 

Codes Write-Protection Level 

NO (or N) No write-protection; background or 
foreground programs may write on the 
file. 

BG (or B) Write permitted by background pro- 
grams only. 

FG (or F) Write permitted by foreground pro- 

grams only. 

Background programs may write on 
the file if an SY keyin is in effect. 

SY (or S) Write permitted by RBM only. Fore- 

ground or background programs may 
write on the file if an SY keyin is in 
effect. 

If the wp parameter is omitted, the default write- 
protection level is NO. 



M dn,BTL Input the bad track list from device "dn" and 

move it into the system tables. No areas will be added to 
the Master Directory in core. 
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Q name Queue specified program for subsequent- 

execution in nonresident foreground. As soon as this space 
is free, the requested program is loaded. If the queue 
stack is full or if the specified program is not found in the 
directory, an error message is output on the assigned fore- 
ground opib, DO, 

Rdn[,ari,ar2i">)V||] Remove areas from the Master Di- 

rectory. If no areas "ar;"are listed, all areas on the device 
will be removed from the Master Directory. For the cart- 
ridge disks which contain a bad track list (A/bdels 7251/52 
and 3231/32/33), the bad track list is removed from the 
system tables. If any files are in use within the areas, re- 
moval does not occur and a ! I KEY ERROR, IN USE message 
is output. An X (abort) keyin to abort a background program 
or an UL (force unload) keyin to unload a foreground pro- 
gram may overcome an IN USE situation for removal. 

RAnn Xerox 530 systems only. Allow connection 

by dial-in of a remote-assistance terminal to the specified 
device number (that must be assigned to a Xerox Model 4194 
or equivalent device). Following execution of this key-in, 
the remote-assistance capability is automatically involved 
upon detection of a ring indication on the data set for a 
specified device. This key-in is applicable only to data 
sets with an automatic answering feature; e.g., a Bell 
Series 103A or equivalent. 

A foreground receiver (X'1B3') may be executed following 
completion of the remote connection. 

RE dn Model 530 systems only. Allow connection of a 

remote assistance terminal to the specified device number 
(which must be assigned to a Xerox Model 4191, 4192, 4193, 
or 4194 terminal). Following execution of this key-in, 
the remote assistance terminal capability is invoked by com- 
pleting a telephone connection with the data-set for the 
associated device. 



RC 



CHAN, Chan 

DEV.dev 

DFN,dfn 



OPLB, 



Jfdun 
loplb 



m 



key -in. 



Reset the I/O error and I/O access 
counters for either one or all chan- 
nels, as specified by the form of the 



whe 



chan is a one- or two-digit hexadecimal channel 

number. The limits on chan are <chan < IB. 

dev is a two-digit hexadecimal device address. 

dfn is a one- or two-digit device file number (DFN) 
in hexadecimal. 

fdun is a FORTRAN device unit number. If the 

second parameter begins with "F:" or a numeral, 
an fdun is assumed. 



tt 



op 

"f" 

B 



lb is a two-character operational label. 

if present, indicates that the specified oper- 
ational label or FORTRAN device unit number is 
for the foreground (F) or background (B). If not 
specified, background is assumed. 



If no parameter is specified, all channel error and access 
counters are reset. (All channel and device numbers speci- 
fied must have been declared at SYSGEN time.) 



RD dn Model 530 systems only. Disconnect the remote 

assistance terminal from the specified device number (which 
must be assigned to a Xerox Model 4191, 4192, 4193, or 
4194 terminal). 

S Continue processing if Monitor is in an idle or wait 
state. If there is a waiting background program, continue 
processing that program. If there is no background program, 
begin reading control cards from the CC device. (Monitor 
can get into the wait state from a W key-in or IPAUSE com- 
mand or into idle from a IFIN command.) 



SY[,S] Permit modification of system files on the RAD 

to take place until the next IJOB or !FIN command is en- 
countered. This key-in is a double check (similar to the 
FG key-in) to prevent accidental destruction of the RAD 
files. Since this key-in is normally input in response to a 
IPAUSE command, the optional S will clear the wait state, 

T hrmn Reset the RBM system time, hour and minutes. 



T hr,mn 



Alternate version of T hrmn. 



TC nn Cause an I/O timeout to occur on the channel 

associated with hexadecimal device address nn. This keyin 
will initiate a retry of an I/O operation for a device which 
was formerly in need of operator intervention. In systems 
with Clockl the retry will be automatic after 30 seconds 
but if Clockl is excluded, the operator must perform this 
key-in. This key-in is not required if the device is in the 
"manual" condition, merely return the "automatic" condi- 
tion and the I/O operation will complete. 

UL Force an unload of the program occupying the non- 
resident foreground area. Note that operator key-ins can 
Interrupt the background program at any time. Operator 
intervention cannot take place while there are active fore- 
ground programs, and will be delayed until they terminate. 



W 



Background goes into a wait state. 



Recognized only if a disk pack unit has been declared at 
system generation. 



X Abort the background job with any dumps requested, 

and output error code OP and a printed message showing 
the location of last background instruction executed. If 
the Postmortem Dump program is already active, it will be 
terminated. 

Z Terminate the current background job including the 
Postmortem Dump program without performing postmortem 
dumps (abort code ER is output). 
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4. MONITOR SERVICE ROUTINES 



BRANCHING TO SERVICE ROUTINES 

Under RBM, foreground and background programs may make 
calls on the Monitor to perform various services or privi- 
leged operations. (See Table 6.) For background requests, 
a branch to protected memory will trigger the protection 
routine which examines the branch for validity. If the pro- 
tection violation is one of a permissible set of "controlled" 
violations/ the branch is permitted; otherwise, the back- 
ground job is aborted with a suitable error message giving 
the location to which the branch was attempted. If the 
branch is valid, the protection routine will permit the 
branch to the appropriate Monitor service routine. 

All service routines are completely reentrant. Hence, they 
can be used by multiple tasks on a completely independent 
basis. Table 6 shows the routines requiring temporary space 
in the user's temp stack. 

There are two different methods of executing a branch to 
one of these Monitor service routines: the conventional 



method is to declare the service routine name as an ex- 
ternal reference and have the Overlay Loader satisfy the 
reference at load time. (In this case, the address literal 
will be in the user's program, and will be filled in by the 
Overlay Loader.) The other method is to branch indirectly 
through the address literal in the zero table (see Appen- 
dix A) using the absolute address given in Table 6. This is 
a useful technique for an absolute foreground program as- 
sembly, or for a processor or other programs that are self- 
relocating. It also requires less program space and may 
make it unnecessary to reload a permanent program following 
an update SYSGEN. 



The B register is always saved and restored since it is used 
to point to temporary space. All other registers are vola- 
tile. The return address (specified by the L, T, or A regis- 
ter) must point to the background area if the routine is 
called (branched to) from the background. Otherwise, a 
protection violation abort occurs. 



Table 6. Transfer Vector for Monitor Services 



Addi 


ess 


Routine 


Fj: 
B^ 
O 


Purpose of this Routine 


Words of Temp Required 


Dec. 


Hex. 


Min. 


Max, 


199 


C7 


MrFSAVE 


F 


M:SAVE Function if all registers previously Saved 








200 


C8 


M:IOEX 


O 


Device-Dependent I/O Driver 


16 


16 


201 


C9 


M:READ 




Device-Independent Read Routine 


19 


51 


202 


CA 


M:WRITE 




Device-Independent Write Routine 


19 


51 


203 


CB 


MiCTRl" 




Device-Independent Control Routine 


50 


62 


204 


CC 


M:DATIME^^ 




Calendar Date and Time of Day 


37 


37 


205 


CD 


MrTERM 




Normal Termination of Background 








206 


CE 


M:ABORT 




Abnormal Termination of Background 








207 


CF 


M:SAVE 


F 


Save Registers on Real-Time Interrupt 








208 


DO 


M:EXIT 


F 


Restore Registers on Foreground Exit 








209 


Dl 


M:HEXIN 




Hexadecimal to Integer Conversion 








210 


D2 


MrlNHEX 




Integer to Hexadecimal Conversion 








211 


D3 


M:CKREST 


F 


Checkpoint/Restart Background 





65 


212 


D4 


M:LOAD*^ 




Load Nonresident Foreground or transfer control to 
another background task 


32 


32 


213 


D5 


MrOPEN^^ 




Open Blocking Buffer for RAD File 


32 


32 


214 


D6 


M:CLOSE^^ 




Close Blocking Buffer for RAD File 


33 


33 


215 


D7 


MrDKEYS 




Read Data Keys 








216 


D8 


M:WAIT^^ 


B 


Execute Wait Loop from Background 


34 


66 


217 


D9 


MrSEGLD 




Load Overlay Segment 


29 


61 


218 


DA 


MiDEFINE^* 


B 


Define RAD Files in Background Temp Area 


32 
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Table 6. Transfer Vector for Monitor Services (cont. ) 



Address 


Routine 


B^ 
O 


Purpose of this Routine 


Words of Temp Required 


Dec. 


Hex. 


Min. 


Max. 


219 
220 
221 
222 
223 
224 
225 


DB 

DC 

DD 

DE 

DF 

EO 

El 


M:ASS1GN^ 

M:POP 

M:RES 

M:OPFILE 

M:RSVP^^ 

M:DOW" 

M:C0C" 


F/O 
F/O 
F/O 


Assign Operational Labels 

Release Dynamic Temp Space 

Reserve Dynamic Temp Space 

Convert Operational Label to Device-File Number 

Reserve or Release Peripherals 

Diagnostic Output Routine and Error Logger 

Communications Handler 


37 







39 

32 

44 


51 







71 

64 

44 


F = foreground only; B = background only; O = SYSGEN option. 

These routines are nonresident RBM overlays. All nonresident REM overlays require a minimum of 32 temp memory 
locations to load the routine. 

Notes: 1. To branch to one of these routines, branch indirectly through the specified address above after RCPYI P, L 
(except M:RES which is called following an RCPYI P,T). 

2. The minimum temp space required is the number used by the routine itself. The maximum temp space is the 
number required by this routine and those it calls, plus 19 if any of the routines are nonresident RBM over- 
lays. For example, M:READ (19) may call Q:ROC to load MrOPEN (13) and Q:ROC may reenter M:READ 
(19) to load the overlay. A total of 51 temp memory locations may be used. 

3. Normally, M:SEGLD requires 29 temp memory locations. However, 61 are required to output the message 
!! BEGIN SEG xx. This is an RBM assembly option (i.e., #SEGXX = yes). 

4. MrCKREST requires 65 temp memory locations if the checkpoint is performed at the priority level of the 
calling task and the message 1 IBKG CKPT is to be typed out. This message can be suppressed if bit 8 
of R:SYFG is set, in which case MrCKREST requires 33 temp memory locations. 

5. Use of any device that has a nonresident device dependent I/O edit or error recovery routine associated with 
it requires 51 temp memory locations by M:READ/M: WRITE. These include KP, PT, LP, B7, CR, and CP. 
However, if one of these devices is not ready, 83 temp memory locations may be required. 



Certain Monitor service routines are nonresident overlay 
routines. The Monitor subroutine Q:ROC controls the load- 
ing of the RBM overlay area. The following Monitor ser- 
vice routines are nonresident overlay routines: 



M:ASSIGN 
M:CLOSE 
M:COC 
M:CTRL 



M:DATIME 
M:DEFINE 
M:DOW 
MrLOAD 



M:OPEN 

M:RSVP 

M:WAIT 



Actually, portions of the above routines are resident. The 
resident portion of M:CLOSE, for example, is as follows: 



M:CLOSE 



RCPYI 

B 

DATA 



P,T 

Q:ROC 
•id nn' 



where 
id 



represents the segment identifier of the non- 
resident overlay section of M:CLOSE. 



nn is the temp stack requirement. 



Q:ROC will call M:RES to reserve the appropriate amount 
of temp space, will read in the required segment, and will 
transfer control to the overlay routine which runs and re- 
turns to Q:ROC. Q:ROC will reload the overlay area if 
appropriate^ and will then release the temp space and re- 
turn to the caller by a call to the Monitor service routine 
M:POP. Particular attention should be given to the maxi- 
mum temporary stack requirements of these routines. 



M:IOEX 



SERVICE ROUTINES 

(General I/O Driver - SYSGEN optional) 



M:IOEX provides direct control by background programs, 
the Monitor, or foreground real-time programs over all I/O 



If the overlay area was originally occupied by an active 
Monitor service routine, the routine must be reloaded. If 
the requested routine is the one occupying the overlay area, 
no loading will be required. 
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operations on the buffered I/O channels for centralization 
of I/O interrupts. All M:10EX control functions are ex- 
empt from channel time limits. The calling sequence is 



LDX 

RCPYI 

B 



odrlst 

PA 

MrlOEX 



where adrlst is a pointer to the argument list, which is a 
set of twO/ three, four, or five consecutive words in the 
user's program or in a temporary stack. This argument list 
appears as follows: 

word 



C 



D 



OP 



1 



where 



6 7 8 



12 13 15 



F = if word 1 is an operational label or device 
unit number. 

= 1 if word 1 is a device file number. 



= 1 if AIO Receiver is specified in word 3 (fore- 
ground option only). 

= if no AIO Receiver is specified. 

= 1 if AIO Receiver is acknowledged on zero- 
byte -count interrupt. 

= if acknowledged on channel -end only. 

= 1 if a user-written command chaining receiver 
is specified (foreground option only). 

= if no command chaining receiver is specified 
(default command chaining to be used). 

= 1 indicates that the device has been marked 
"down" by a DU key-in. 

= indicates that the device is not down. 

I/O may not be performed on a down device 
unless bit 7 of the request order word isa one; 
otherwise, device-unavailable status is re- 
turned. Similarly, I/O may not be performed 
on an "up" device unless bit 7 of the request 
order word is a zero. 

The D bit is intended for the use of RBM 
diagnostic programs to allow testing of fail- 
ing devices. User programs should code with 
the D bit reset (D = 0). 



OP is the code for the operation to be performed: 

OforSIO 

1 for TIO 

2 for TDV 

3 for HIO 

4 for "check previous data transfer" 
word 1 



Operational label or file number 



word 2 


15 


Address of first lOCD (for SIO only) 



word 3 


15 


Address of AIO or CC Receiver (for SIO only) 



15 



If bit A = 1 (word 0), then word 3 is a pointer to the AIO 
receiver. If A = and bit C "= 1, then word 3 is a pointer 
to the command chaining (CC) receiver. If both A = 1 and 
C = 1, however, on additional word is required as a CC- 
receiver pointer: 

word 4 



Address of CC Receiver (for SIO only) 



15 



Return to the user's program is to the location in register L 
on entry to M:IOEX. Register B is always saved. 

The Overflow (OI) and Carry (CI) Indicators, the A regis- 
ter, E register, and (in some cases) X register are used to 
return status information on the required operation. The 
complete list of status codes is given in Table 7. 

If a device has been declared "down" through the operator's 
use of a DU key-in, only M:IOEX calls having bit D = 1 
(in word 0) are permitted access to the device. This is in- 
tended to allow RBM diagnostic programs to test failing 
devices. Otherwise, (D = 0), a device-unavailable status 
is returned (rE = -1, rA = 9, rX = 0). Conversely, if a de- 
vice has not been declared down, lOEX calls with D = 1 
are not permitted; a device-unavailable status is returned 
to the diagnostic program. 

Note that no I/O error recovery is attempted. DSBs and 
OSBs are just as received from the I/O system hardware. 
These status returns are organized so that a quick and simple 
test will show the nature of the return. If the user wishes 
to keep trying to initiate the I/O operation or keep check- 
ing for completion, it is possible to loop back to the call 
to M:IOEX. 
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Table 7. Return Status from MrlOEX 



Operation 


A/kijor Status 


OI 


CI 


E Register 


A Register 


X Register 





I - 7 


8-15 


0-7 


8-15 


0-15 


SIO, TIO, 
TDV, HIO 


Device number 
not recognized 


I 


I 







Recognition Code 







All 


Invalid call or opib 








1 




4 or 8 







Opib set to zero 













2 







Device unavailable 








1 




9 







SIO 


SIO cannot be 
accepted 





I 





Current DFN 


TIO 
DSB 


Dev. No. 





Channel busy 











Active DFN 


TIO 
DSB 


Dev. No. 


-1 


Successful 
initiation 











Current DFN 


SIO 
DSB 


Dev. No. 





TIO 


SIO cannot be 
accepted 





1 





Current DFN 


TIO 
DSB 


Dev. No. 




Other 













TDV 


Device abnormal 
condition 





I 





Current DFN 


TDV 
DSB 


Dev. No. 




Device normal 
cocKfition 













HIO 


Device operating 
when HIO 
received 





1 





Current DFN 


HIO 
DSB 


Dev. No. 




Device not oper- 
ating when HIO 
received 













I/O check 


I/O operation 
in progress 


1 








Current DFN 


SIO 
DSB 


Dev. No. 






I/O completed 
unusual end 





1 





E 

Flog 
(Bit 7) 


OSB 


AlO 
' DSB 


Dev. No. 


Byte Count 
Residue (from 
even I/O 
channel reg- 
ister at chan- 
nel end) 


I/O completed 
normal end 











Use BXNC to test both conditions simultaneously. 


Legend: 

DSB = Device Status Byte 

Dev. No. = Device number of current device 

OSB = Operofional Status Byte 
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If an AIO and/or a CC receiver is specified, it must be a 
closed subroutine, is executed at the I/O interrupt level, 
and must return to the I/O Interrupt Task. The same gen- 
eral usage rules govern both: no monitor services may be 
called, all registers are considered volatile, and processing 
must be brief so as not to interfere with other on-going I/O. 
On entry to the CC receiver, register L contains the return 
location and register X contains the DFN; on exit, if reg- 
ister A is negative, software command chaining will not be 
performed; if zero or positive, such chaining will take 
place. (See "M:IOEX Functions", below, for functional 
descriptions of AIO and CC receiver operation. See also 
"End Action" in Chapter 5 and "AIO Receivers" in Chap- 
ter 6. ) 

The user can use M:IOEX to read/write on the RAD or any 
peripheral device that uses standard Xerox peripheral re- 
sponses. For input/output operations to the RAD, the user 
must first give a seek order and then the appropriate data- 
transfer request. The user must also perform his own file 
management. If multiple tasks use the RAD, they must 
cooperate in some way so that the seek address is not modi- 
fied by some higher-level task before the data operation 
is initiated. Note that a user must always issue a "Check" 
(op code of 4) after each read or write request. 

The following special rules govern the use of M:10EX for 
<3 RAD: 

1. A device-file name of the form XXdn must be included 
in the set of SYSGEN input parameters following the 
heading DEVICE FILE INFO, where XX indicates that 
this is a special -purpose device for use with MiIOEX, 
and dn is the hardware device number of the RAD. The 
M;IOEX calling sequence must contain the device- 
file number corresponding to this device-file name, 

or must contain an operational label that is assigned 
to the device-file number. 

2. The set of SYSGEN input parameters following the 
heading RAD ALLOCATION must include provisions 
for reserved tracks that are not to be included in the 
areas allocated for RBM file management. This can be 
accomplished by 

a. Assigning the system RAD too device number other 
than XXdn. This method requires two RADs, one 
containing the RBM area assignments, and the 
other available for use with MrlOEX. 

b. Allocating only part of a RAD for RBM area assign- 
ments, leaving the remainder available for use 
with MiIOEX. 



c. Allocating part of a RAD for M:IOEX use by speci- 
fying that a number of tracks be skipped between 
RBM areas with an allocation parameter of SK = n, 
where n is the number of tracks. 

d. Any meaningful combination of the above. 



M:IOEX FUNCTIONS 

TIO, TDV, HIO In these operations, the request is per- 

formed immediately and the device status bytes are returned 
if the device is recognized. The AIO Receiver is ineffec- 
tive for these operations. 



SIO The SIO operation is initiated if there is device 

recognition and the channel is free (which may not be the 
same as "device free" or "device controller free" for chan- 
nels with several devices). 

The SIO is issued even if the device is in the manual mode. 
It is therefore the responsibility of the user's program to test 
for the manual mode both before and after the SIO request, 
and to inform the operator by a suitable message. 

An HIO can be used to abort an I/O operation. This results 
in setting the channel end device ready for a new activity. 
Since status is returned, an I/O check operation is not 
required. 

Protection checks are performed only for background I/O 
requests. Background is not permitted an AIO Receiver, 
and a receiver is ignored if requested from the back- 
ground. Background operations specifying data chaining 
are not allowed. This is due to the structure of the lOCDs, 
I/O Data Tables, and the requirements for the absolute 
protection of foreground programs (see "End Action" in 
Chapter 5). 

The user of M;IOEX must be thoroughly familiar with 
machine-level I/O operations in general, and in particular 
with the execution of the SIO instruction as described in 
the appropriate Xerox computer reference manual. M:IOEX 
does not modify the user's lOCDs or device-order bytes in 
any way. 

When using foreground data chaining it is very important 
to set the interrupt flags on all lOCDs, since an unusual 
end condition in one of the lOCDs without the interrupt 
flag being set will cause the I/O to terminate without an 
interrupt, and the channel may then "hang up" waiting for 
the interrupt because the RBM tables indicate that the chan- 
nel is still busy. 

In addition to hardware- executed data chaining, RBM pro- 
vides a software convention for command chaining. Its 
operation and control is analogous to data chaining and 
involves an extension of the normal, hardware-determined 
lOCD and I/O-control-table formats. The use of command 
chaining is fully described in the RBM/System Technical 
Manual, 90 11 53 (see also the RBM I/O control tables 
illustrated therein for usage examples). If a command 
chaining (CC) receiver is specified in the M:IOEX argu- 
ment list, it is entered at I/O completion time prior to 
the execution of software command chaining, at the I/O 
interrupt level. The purpose of the CC receiver is to allow 
the user to make a real-time decision as to whether or not 
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a command-chained operation is to be continued. The 
content of register A on return from the CC receiver over- 
rides standard RBM command chaining control (see below): 
if the A register is negative, chaining is to be terminated; 
if zero or positive, continued. (The receiver is entered only 
if there is another operation to be performed in the user's 
I/O table. ) If no CC receiver is specified, a default RBM 
receiver is entered and default command-chaining control 
is exercised: the operational status byte (bits 0-7 of the 
even channel register) is tested for transmission error, chain- 
ing modifier, or unusual end. If any of these conditions is 
true, command chaining is terminated. Since neither data 
chaining nor software command chaining operations are per- 
mitted for background programs, the specification of a CC 
receiver from the background is ignored. 

The Monitor does not alter the user's data in any way. If 
an I/O interrupt is received and there is no AIO Receiver 
specified (and the device is still busy), the I/O interrupt 
is ignored and the channel remains active. 

The user's program must determine whether there wasa chan- 
nel end or an unusual end condition. If the return is for a 
busy device or channel, the program can loop on this re- 
quest until the operation is successful. 

Since only higher priority tasks can take control from the 
task issuing the request, the routine issuing the request 
gains control of the desired device and/or channel as soon 
as the current operation is complete. The M:10EX routine 
inhibits interrupts for a period of less than 100 microseconds 
during the loading of the I/O channel registers and the set- 
ting of the activity status for the device and channel. Thus 
a higher priority task can always interrupt up to the point 
when the I/O channels are loaded during the initiation of 
an I/O request. 



I/O CHECK This operation tests for channel end on the 

previously requested I/O operation by testing certain flags 
within the RBM I/O tables. The flag is set by the I/O 
Interrupt task when the device interrupt occurs. Thus, 
no TIOs are required to determine when the operation is 
complete. Since the TIOs do consume some I/O time 
(particularly if executed repeatedly in a test loop), the 
method of checking for I/O completion described herein 
is desirable. The Monitor saves the operational status 
byte and the byte count residue from the completion of 
the I/O operation, even though another device may have 
used the channel before the end-action check is made by 
the requesting task. 

The following restrictions are pertinent in using M:IOEX: 

1. RBM will not necessarily recover automatically from 
the results of an HIO for most devices. Operator 
intervention may be necessary. 

2. Background programs cannot specify data chaining or 
command chaining. 

3. Background programs must specify an interrupt in all 
lOCDs. 



M:REAO 



(General Read Routine) 



M:READ provides device-independent input with standard 
editing and checking. Standard error detection and cor- 
rection is optional on each call. The calling sequence is 



LDX 


adrlst 


RCPYI 


P,L 


B 


M:READ 



where adrlst is a pointer to the argument list, a set of two 
to six words in the user's program or in a temporary stack. 
This argument list appears as: 

word 



F 


A 


w. 


E 


R 











Order 



0^12345678 15 

- \j \ V i 
where '' 

F = 1 if a device-file number is specified. 

= if an operational label or device unit number 
is specified. 

A = 1 if an AIO Receiver address is specified (speci- 
fiable by foreground only). 

= if no AIO Receiver is specified. 

W = 1 if wait for completion is unconditional. 

= if wait is for "initiate and return" only; return 
is immediate if operation cannot be started 
at once. (The minimum-seek algorithm does 
not apply to RAD "no wait" operations.) 

E = 1 if standard error recovery is to be performed 
at channel end. 

= if no error recovery is to be attempted. 

For RAD or disk pack, five attempts for error re- 
covery will be made if E is specified; 10 attempts 
will be made for magnetic tapes. If I/O without 
a WAIT is specified, error recovery will not be 
performed until a "Check" is issued by the user. 
See RAD and Disk Pack Error Recovery. 



1 direct access: a RAD record displacement is 
specified (granule or logical record number, 
applicable only to random files). If the file 
is not random, calling sequence error is 
returned. 

sequential access: a RAD record displacement 
is not specified and implies sequential access 
of random files or sequential files. 
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If the order is "Check previous output for completion (04)", 
the 'R' is used as follows: 

R = do not retry the operation if operator inter- 
vention is required; instead, return "Operator 
Intervention Required". 

= 1 retry the operation, notifying the operator if 
intervention is required. 

D = 1 indicates that the device has been marked 
"down" by a DU key-in. 

= indicates that the device is not down. 

I/O may not be performed on a down device 
unless bit 7 of the request order word is a one; 
otherwise, device-urravailable status is returned. 
Similarly, I/O may not be performed on an "up" 
device unless biy 7 of the request order word is a 
zero. 

The D bit is intended for the use of RBM diagnos- 
tic programs to allow testing of failing devices. 
User programs should code with the D bit reset 
(D-0). 

Order is one of the following permissible pseudo 

input orders: 

Order Operation 



X'OO' Return information about this device 
and file. See Return Registers. 

X'02' Read binary. 

X'04' Check previous input for completion 
(after a "no wait" initiation). 

X'06' Read automatic. 

X'OC Read backward (9-track magnetic 
tape only). 

X'lO' Return information on FORTRAN 
associated files. 



word 1 



Operational label or file number 




word 2 



15 



Address of buffer to buffer to receive data 







15 



Buffer must be in background if called by a background 
program. Also, buffer must not overlap active temporary 
storage or unavailable memory. 



word 3 




Number of bytes to transmit 







15 



Byte count must be an even number when reading from RAD 
files and cannot exceed 65,534. For all other devices the 
byte count may be either even or odd but cannot exceed 
8192. If the byte count is even, input data stored in the 
user's buffer starts in the left-hand byte; if odd, data starts 
in the right-hand byte. 



word 4 




AIO Receiver or RAD record displacement 







15 



If A = 1 (in word 0), this is the address of the closed AIO 
Receiver subroutine called by the I/O interrupt task at 
channel end. If A =0, this is the RAD record displace- 
ment (granule or logical record). 

word 5 



RAD record displacement (optional) 







15 



If an AIO address is specified (A = 1 in word 0), word 5 
indicates the displacement from the start of the file (start- 
ing with a displacement of zero). Transfer starts at the 
beginning of the indicated file unit. Word 4 is RAD file 
unit displacement if A = 0. 

While blocked and unblocked random files may be ac- 
cessed directly or sequentially, the usage modes should not 
be freely mixed. Note that if the R bit is not set for ran- 
dom files, the file is processed sequentially. 



RETURN REGISTERS 

Return is always to the location specified in the L register. 
The B register is always saved. 

The E, A, and X registers all contain status information on 
the return, as shown in Table 8. I/O completion codes 
are listed in Table 9. Return is always immediate if there 
is a calling sequence error, in which case the E register is 
negative upon return. For the case where a wait is speci- 
fied, the l/O is initiated and the M:READ routine loops 
until the operation is complete. When "initiate and no- 
wait" is specified, an SIO is issued before the return if the 
device is recognized, is currently free, can accept an SIO, 
and is not in the "manual" mode. If any one of these con- 
ditions is false, the M:READ routine returns immediately 
with the appropriate indicators set. If the channel or de- 
vice is busy, the caller can either loop back to the call to 
M:READ or switch to another device. The "wait" flag has 
meaning whether this is an initiate or a check order. Error 
recovery is attempted if specified before the final return is 
made. 
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Table 8. Return Status from M:READ, MrWRlTE, M:CTRL 








Operation 


Major Status 


Action 


E Reg. 


A Reg. 


X Reg. 


All operations 


Operational labels not valid. 


Return immediately. 


-I 


8 


tt 




Calling sequence error. 


Return immediately. 


-I 


4 


tt 




Operational label is set to zero. 


Return immediately. 





2 


t 




RAD or nrragnetic tape file positioned 
at EOT. 


Return immediately. 





4 


t 




Irrecoverable I/O error. 


Return after error recovery 
attempt, if any. 


-I 


1 


t 




Device has been declared unavailable. 


Return immediately. 





9 


t 


Initiate 


Blocking buffer not available. 


Return immediately. 





10 


t 


Initiate I/O 
and no wait 


Channel and device are free and in 
automatic. 


Initiate I/O and return. 
Status in X register only 
meaningful if A = 1 in the 
call and the A register is 
zero upon return. X = -1 
if the AIO Receiver will not 
be acknowledged; other- 
wise X = 0. 








Oor-l 




Channel and/or device are busy. 


Return immediately. 





-1 


t 




AiAanual intervention is required 

(manual mode or device not recognized). 


Return immediately. 


-1 


-1 


t 




Completion available without I/O 
being initiated. 


Return immediately. 


Oor-l 


See 
Table 9 


t 


Check and 


I/O still in progress. 


Return immediately. 





-1 


t 


no wait 


I/O complete. 


Return after end-action, 
if any. 


Oor-l 


Comple- 
tion code 
(Table 9) 


Byte 
count 


Initiate and 
wait 


Channel and device are free and 
automatic. 

Channel or device are busy. 

Device number is not recognized or is 
write protected. 


Initiate I/O and wait for 
completion. 

Wait and keep trying. 

Type out the proper mes- 
sage to operator and retry. 


Oor-1 


See 
Table 9 


Byte 
count 




Device is in manual mode. 


Type out EMPTY message 
to operator and retry. 








Initiate and 
wait or check 
and wait 


I/O still in progress. 
I/O complete. 


Wait, and keep checking. 

Perform any end-action 
and return. 


Oor-l 


Comple- 
tion code 


Byte 
count 
trans- 
mitted 


Unspecified. 












Sector size (in b) 


^tes) of the device containing the BT area. 
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Table 9. I/O Completion Codes 



E Reg. 


A Reg. 


Meaning 


Comment 








Operation successful. 


X register contains the number of data bytes transmitted. 


-1 


-1 


Operator intervention is required. 
Normally/ this error is equivalent 
to an I/O error. 


The operator was appraised during the error recovery pro- 
cedure that intervention is required. 


-1 


1 


Irrecoverable I/O. 


If error recovery was specified, the maximum number of 
retries have been unsuccessfully attempted. 





2^ 


Operation not meaningful for this 
device. 


Either an operational label was assigned to file zero or I/O 
operation is not meaningful for the device. 





3^ 


End-of-file encountered. 


Significant only for magnetic tape and sequential RAD 
files (except in automatic mode when significant also for 
cards, paper tape, and keyboard/printer). 





4^ 


End-of-tape encountered. 


Significant only for magnetic tape or sequential and 
random-access RAD files. 





5 


Incorrect record length. 


For read operations, the requested byte count does not 
equal the device's physical or logical record size. For 
write operations, the requested byte count is greater than 
the device's physical or logical record size. For either 
read or write, the actual byte count transmitted is returned 
in the X register. 





6 


No I/O pending for this check 
operation. 


Error in I/O buffering. An initial no-wait I/O request 
either was not issued or was rejected. 





/ 


Device is write-protected. 


Significant only for writing on magnetic tapes and RAD 
files. 





8 


Beginning-of-tape encountered. 


Significant only for reading backward and for positioning 
magnetic tapes and sequential RAD files via M:CTRL, 





9^ 


Device unavailable. 


Device was declared "down" through use of DU operator's 
key-in. 





10^ 


Blocking buffer unavailable. 


Significant only for blocked RAD files- 


Status a\ 


so meoninc 


ful under initiate I/O and no wait. 





On a check operation, the byte count returned in the X 
register may not be meaningful if the calling sequence does 
not specify the same count as the initial read. 

If the order code is X'OO', the following device status in- 
formation is returned. 

Register Status Information 

A Device name (EBCDIC): 

RD = RAD/disk file 
KP = keyboard/printer 
PT = paper tape 



Register Status Information 



CR = card reader 

CP = card punch 

MT - magnetic tape 

LP - line printer 

PL = plotter 

LD = logical device. (E) not 
meaningful 
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Register Status Information 



X 



TDV device status byte (bits 0-7) and 
physical device number (bits 8-15). 

Physical standard record size (bytes) for 
non-RAD files or granule size for RAD 
files. 



If the code is X'lO', the follov/ing status information is re- 
turned for random or packed files: 

Register Status Information 

A Address of the FORTRAN associated vari- 

able (PTR). 

E File units per FORTRAN logical record. 

X File unit in bytes (granule or logical rec- 

ord size). 

If a read is attempted to a flawed track in disk pack files, 
the header of the flawed track is read to determine its 
alterrxite. The alternate track is then read as if it were 
the original. 



M:READ FUNCTIONS 

M:READ is designed to read one logical record from the 
specified device regardless of device type and whether the 
record is EBCDIC or binary. Therefore, M:READ will set 
up the proper order bytes for the actual device, using the 
"pseudo order byte" given in the call to M:READ only as 
a guide. The user may request fewer bytes than are in the 
record and only this number will be returned in his buffer. 
However, if more bytes are requested than are in the 
record, only the bytes in the record will be read. In 
any case, the actual number of bytes read will be re- 
turned in the X register when the completion code is re- 
turned, and if this is not the same as the number of bytes 
requested, an "incorrect length" code will be returned. 
While it is not always necessary for the user to check all 
possible return codes, it may be useful to print them out to 
aid in debugging. 

If an attempt to read a record from magnetic tape results in 
the detection of an irrecoverable transmission error and 
incorrect length condition, and if fewer than eight bytes 
were read from tape, it will be skipped and the next record 
on tape will be read. 

Using MrREAD, a user can read 80 EBCDIC bytes regardless 
of whether they come from cards, paper tape, magnetic 
tape, keyboard/printer, or RAD. MrREAD will perform 
standard editing from paper tape to give a record a format 
identical to card image output. 

By using a "read and no wait" followed later by a "check 
for input complete" the user can effectively overlap input 
and compute. 



The order code X'OO' is used to request information about 
an unknown device, and may be helpful in determining the 
optimum blocking sizes to use. 

When using MiREAD to make requests on a Logical Device 
(refer to Chapter 5 — I/O Operations for a description of 
Logical Devices), where Logical Device is used in the 
sense of a mechanism to facilitate information transfer be- 
tween tasks independently of real devices, the following 
observations should be made: 

1. Channel timeout does not apply. 

2. Read backward is not meaningful. 

3. Read Blrrary and Read Automatic are not differentiated. 
Only one record, as specified by buffer address and 
byte count, is transferred per request. 



REAL-TIME PRIORITY 

All of the I/O routines are reentrant, and any input can be 
interrupted for a higher-priority task up to the "point of no 
return" of setting Monitor status flags and loading channel 
registers. External and Internal interrupts are inhibited for 
up to 100 microseconds of CPU time during the actual SIO 
sequence. Keeping a high priority task active and looping 
on an input request to a busy device enables the task to 
seize control of the channel or device as soon as the cur- 
rent I/O operation completes. 



SPECIAL EDITING FOR CARD READER 

Read Automatic. Any cards with a "1" and "2" punch In 
column 1 are automatically read as binary; all other cards 
are read as EBCDIC or BCD. (For nonstandard binary cards, 
the user must use "read binary".) It is possible to specify 
that all cards from a certain file are to be read as BCD and 
converted by the MrREAD routine to EBCDIC before being 
returned to the user. Since this would apply only to one 
file, it is possible to read some cards in EBCDIC and some 
in BCD from the card reader. (BCD card codes are pro- 
duced by an IBM 026 keypunch, and EBCDIC card codes 
are produced by an IBM 029 keypunch. ) The EBCDIC 
record size is 80, and the binary record size Is 120 bytes. 

An Incorrect length status Is returned If the requested byte 
count does not exactly match. An "end-of-file" status Is 
returned when an EBCDIC card that begins with !EOD Is 
Input Into the user's buffer. An "end-of-tape" status Is 
never returned. 



Read Binary. An "incorrect length" status Is returned if 
the requested byte count does not equal the maximum num- 
ber of bytes requested in the calling sequence. The num- 
ber of bytes requested, up to a maximum of 120, are Input 
in the user's buffer. "End-of-file" and "end-of-tape" status 
codes are never returned. 
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SPECIAL tDITING FOR PAPER TAPE OR KEYBOARD/ 
PRINTER 

Read Automatic. All input from paper tape or keyboard/ 
printer is initiated in a one-byte-at-a-time mode. From 
paper tope, the read order is always "read ignoring leader". 
If the first byte is a code of X'lC, X'3C', X'FF', X'9F', 
X'BF', X'DF', or X'78' (which can only happen with paper 
tape), the MrREADroutine switches to a binary mode and 
reads up to 119 more bytes (for a total of 120 in the record). 
The code byte will be the first byte in the user's buffer. 

Code bytes are all invalid EBCDIC codes in the sense that 
they are not printable graphics or control codes. Since 
they are all supersets of the card reader "1 and 2 punch" 
rule for column one, the same codes for "read automatic" 
can be used for the card reader as for paper tape and, in 
both cases, the code is part of the user's data buffer. If 
the first byte from the paper tape or keyboard/printer is not 
one of the binary codes M:READ continues to read one byte 
at c time until a NEW LINE code is encountered. 

When a NEW LINE code Is encountered, input transmission 
is terminated and the line image is filled out with blanks 
to the requested byte count. The NEW LINE code is not 
transmitted to the user's buffer. (If a NEW LINE code is 
the first code in the input line, it is ignored. ) 

Thus, all EBCDIC records are of variable length, up to the 
maximum requested or until a NEW LINE is encountered. 
Further, EOM and cent (^) have special meanings within 
the user's data line. An EOM causes the entire line up to 
the present position (including the EOM byte) to be dis- 
carded. A ^ sign acts like a backspace. For each ^ sign 
received, this byte and the byte preceding it are thrown 
away. 

When reading binary records in the automatic mode, 120 bytes 
are read regardless of the number of bytes requested. For 
EBCDIC records, the paper tape is read up to and including 
the NEW LINE code. For either EBCDIC or binary records, 
not more than the maximum number of bytes requested is 
transmitted to the user's buffer. The requested byte count 
must be 80 for EBCDIC records and 120 for binary records. 
Any other byte counts result in an "incorrect length" 
status return. 



ignoring leader" by a PATCH. The physical record size 
is the number of bytes requested by the user's input. The 
next record starts immediately following the last byte of 
the previous record and the requested byte count deter- 
mines the end-of-record. "Incorrect length" and "end- 
or-file" status codes are never returned. "End-of-tape" 
status is not returned, even when the paper tape runs off 
the reader. 



Read Binary from Keyboard/Printer. A read binary order 
causes the keyboard/printer to read the exact number of 
bytes specified. RBM performs no editing, and no bytes 
(including NEWLINE codes) are considered control bytes. 
"Incorrect length", "end-of-tape", and "end-of-file" 
status codes are never returned. 



SPECIAL EDITING FOR MAGNETIC TAPE 

Read Automatic or Binary. Automatic and binary modes 
are identical on 9-track tape, and M:READ supports only 
the BCD and packed-binary modes for 7-track tapes. Only 
the number of bytes requested is transferred to the user's 
buffer regardless of the physical record. "Incorrect length" 
status is returned when there are either too few or too many 
bytes in the input record, and the tape is positioned at the 
start of the next physical record. "Incorrect length" will 
not be reported for too many bytes in the input record for 
7-track, packed binary tapes. 

If the tape is positioned past the end-of-tape marker and 
error checking is specified, the device is not started and 
"end-of-tape" status is returned. If error checking is not 
specified, the device is started, and the status returned at 
completion is as in Table 10 except that "end-of-tape" 
status (A=4) is returned if a file mark is sensed. Read back- 
ward operations on 9-track tapes are always permitted past 
end-of-tape. 

The Read Backward order produces a buffer with data In an 
inverted condition. If the tape is at the load point when 
the Read Backward order is given, no data is transmitted 
and "BOT" status is returned. Read Backward will be 
ignored for devices other than 9-track magnetic tape. 



An "end-of-fije" status is returned when an EBCDIC record 
that begins with !EOD is input into the user's buffer. 

Read Automatic from Model 4191 or 4193 Keyboard/Printer. 
A Read Automatic order for a Model 4191 or 4193 keyboard/ 
printer (Model 530 systems only) causes a prompt char- 
acter (/) to be printed immediately prior to reading from 
the keyboard — there is no INPUT light to indicate "read" 
state. Otherwise, the operation is the same as described 
above except that a control -H combination causes the en- 
tire line to be cancelled (discarded) and control-X Is used 
for the backspace (character-erase) function. 

Read, Binary from Paper Tape. The Read Binary order for 
paper tape is "read immediate" unless it is changed to "read 



SPECIAL EDITING FOR SEQUENTIAL RAD FILES 

Read Automatic or Binary. On a RAD, automatic and 
binary modes are identical. When reading from blocked 
files, a blocking buffer must be supplied. If the calling 
program has not specified a blocking buffer, M:READ will 
call M:OPEN to reserve a buffer from the cal ling task's 
buffer pool. If no buffer is available, M:REAO exits with 
a "blocking buffer unavailable" status. 



The user should be thoroughly familiar v/ith the BCD and 
packed-binary mode if 7-track magnej-ic tape is used. See 
the Sigma 7- Track Magnetic Tape System/Reference Man- 
ual, 90 09 78. 
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Compressed records are decompressed by M:READ so thai- 
only the expanded record, without compression codes, is 
input into the user's buffer. 

A byte count can be requested that is less than, equal 
to, or greater than the file's logical record size. The 
number of bytes requested, up to a maximum of the logical 
record size, is always transferred. If the byte count does 
not equal the logical record size, "incorrect length" status 
is returned. In any case, the file is positioned to the next 
logical record, regardless of the byte count transferred. 
For compressed files, the requested byte count is compared 
to the byte count of the expanded record instead of the 
logical record size. "End-of-file" status is returned when 
the file is positioned at the logical EOF. "End-of-tape" 
status is returned when the file is positioned at the logi- 
cal EOT. This is true whether or not error recovery is 
specified. 



A Read Backward order will be interpreted as a Read 
order. 



The error handling procedure is optional on each call to 
M:WRITE. The calling sequence is 



LDX 



adrlst 



RCPYI P, L 

B MrWRITE 

where adrlst is a pointer to the argument list, which is a 
set of two to six words in the user's program or in a temp- 
orary stack. The argument list consists of six words: 

word 



F 


A 


W 


E 


R 





SR 


D 


Order 



01 2345678 
where 
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1 if a device-file number is specified. 

if an operational label or device unit Is 
specified. 



SPECIAL EDITING FOR RANDOM-ACCESS RAD FILES 

Read Automatic or Binary. Automatic and binary modes 
are again identical. For unblocked random files, the 
exact number of bytes requested will be put into the user's 
buffer and "incorrect length" status will not be returned. 
One or more granules will be read to satisfy the byte count. 
RAD space between granules is lost. Unused parts of gran- 
ules are ignored. 



For blocked random files, no more than one record will be 
transferred. A greater byte count request results in incor- 
rect length. The file will always be positioned at the next 
record after o successful transfer. 

If the Read begins or extends beyond the file's ending 
boundary, no data is transmitted and "end-of-tape" status 
is returned. For blocked random files, an end-of-file may 
also occur. This Is true whether error recovery is specified 
or not. 

Note: For all disk files, no transfer will be initiated that 
crosses a track boundary. Instead, It will be broken 
into two transfers: one to transfer to the end of the 
track, and a second to complete the transfer. There- 
fore, in a "no-wait" operation, a check must be 
requested to complete the transfer. If an AIO Re- 
ceiver Is specified, it will be entered each time 
channel end occurs, but it also must be specified in 
each Check operation call. 



M:WRITE (General Write Routine) 

M:WRITE provides device-independent output with stan- 
dard editing and standard error detection and correction. 



A = 1 if an AIO Receiver address is specified. 

= if no AIO Receiver address is specified. 

Note; only a foreground operation can specify 
this. 

W = 1 if wait for completion is unconditional. 

= if wait is only for "initiate and return"; re- 
turn is immediate if the operation cannot be 
started immediately. 

E = 1 if standard error recovery is to be performed 
at channel end for this operation. Five at- 
tempts at error recovery wi 1 1 be made for ro- 
tatlng memory devices and ten attempts will 
be made for magnetic tapes If E is specified. 
If I/O without a WAIT is specified, error re- 
covery will not be performed until a "Check" 
is issued by the user. 

= if no error recovery is to be attempted. 

R = 1 if a RAD record displacement is specified (can 
only be specified for random-access RAD files). 

= if a RAD record displacement is not specified. 

If the Order is "Check previous output for completion (04)", 
the 'R' Is used as follows: 

R - do not retry the operation If operator interven- 
tion Is required; instead, return "Operator 
Intervention Required". 

= 1 retry the operation, notifying the operator If 
Intervention Is required. 
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SR 1 if the user is doing his own blocking to an 

RBM blocked or unblocked sequential RAD 
file and an indication of a possible short 
last record is to be retained in the file di- 
rectory. If the record being written is ac- 
tualiy a short record, a flag will be set in 
the lOCT for later transfer to the file direc- 
tory when the file is closed. The actual byte 
count of the record will be stored into the 
effective last word of the record. If the 
record is not a short record, the lOCT flag 
is cleared; thus this specification is only 
meaningful for the last record. Upon reading 
the file, a Read request for the last record 
(assuming a short record) would result in an 
incorrect record length status (E = 0, A - 5, 
X = actual byte count). 

= if short record logic is not to be invoked. 

The following rules govern the usage of the 
short record flag: 

1. The record must be written from a loca- 
tion that guarantees that the location 
where the effective last word of the 
record (as defined by the actual record 
size) would lie within the domain of the 
task. This should not be a problem since 
the record is normally written from the 
application programs block reserve. Fail- 
ure to do so from a background program 
will result in a calling sequence error 
(E = -1, A = 4). Since the boundaries 
of a foreground program cannot always 
be determined, interference with another 
task can occur, 

2. It is assumed that on Read operations 
the user program is requesting a byte 
count equal to or greater than the actual 
record size. A Read request for less 
than the actual record size would re- 
turn an incorrect record length for each 
read and a transfer of the request bytes 
for each record, including the last rec- 
ord, and may return more data than was 
actually written into that record, since 
RBM has no way of determining the writ- 
ten byte count without reading the en- 
tire record. 



3. The "short record" specification is mean- 
ingful only for unblocked sequential and 
blocked sequential files and is Ignored 
for other devices or files. Only the last 
record in the file retains the short record 
indication. 

4. The "short record" operation results in a 
modification to the users buffer if the 
record is a short record. 



D = 1 indicates that the device has been marked 
"down" by a DU key-in. 

== indicates that the device is not down. 

I/O may not be performed on a "down" device un- 
less bit 7 of the request order word isa one; other- 
wise, device-unavailable status is returned. Si- 
milarly, I/O may not be performed on an "up" 
device unless bit 7 of the request order word is a 
zero. 

The D bit Is Intended for the use of RBM diagnos- 
tic programs to allow testing of failing devices. 
User programs should code with the D bit reset 
(D=0). 

Order is one of the following pseudo order bytes: 

Order Operation 

X'OO' Return information about this device. 

X'Ol' Write binary. 

X'03' Write file mark or lEOD. 

X'04' Check previous output for comple- 

tion (after a "no wait" Initiation). 

X'05' Write EBCDIC. 

X'07' Check write (RAD only). 

X'lO' Return information on FORTRAN 

associated files. 



word 1 





Operational label or file number 





word 2 




15 


Address of buffer containing data 



word 3 




15 




Number of bytes to transmit 









15 



The byte count must be an even number when writing on 
RAD files and may not exceed 65,534. It may be either 
even or odd for all other devices, but cannot exceed 
8192 bytes. If an odd byte count is requested, the first 
byte Is written from the right half of the word and the left 
half Is Ignored. If an even byte count Is requested, the 
byte Is written from the left half of the first word. 
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Output to the card punch assumes an even byte count. An 
extra byte at the start of the buffer Is sent if the count is 
odd. 

word 4 



AIO Receiver or RAD record displacement 
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This is the address of the closed AIO Receiver subroutine 
called by the I/O interrupt task at the channel end, if 
A = } (word 0). If A = 0, this is the RAD granule displace- 
ment (granule or record) 

word 5 



RAD record displacement (optional) 
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If an AIO address is specified (A = 1 in word 0), word 5 
indicates the displacement from the start of the file (starting 
with a displacement of zero). Transfer starts at the begin- 
ning of the indicated file unit. Word 4 is the RAD file unit 
displacement if A = 0. 

Packed and unblocked random files may be accessed randomly 
or sequentially. Note that if the R-bit is not set for random 
files, the file is processed sequentially. 



RETURN REGISTERS 

The return is to the location in the L register. The B regis- 
ter is always saved. 



The status is returned in the E, A, and X registers. Status 
and method of returning status are the same as for M:READ. 



If the code is X'lO', the following status information is 
returned for random or packed files: 

Register Status Information 

A Address of the FORTRAN associated vari 

able (PTR). 

E File units per FORTRAN logical record. 



X 



File record size in bytes (granule size if 
random file, logical record size if packed 
random file). 



If a write Fs attempted to a flawed track in disk pack files, 
the header of the flawed track is read to determine its alter- 
nate. The alternate track is then written as if it were the 
original. 



MrWRITE FUNCTIONS 

MrWRITE is designed to write one physical record on the 
device specified, regardless of the device type. Because 
of differences in Write orders for the card punch, it is 
necessary to specify whether the output record is binary or 
EBCDIC. (For most other devices, the difference is not 
meaningful. ) 

Not more than one physical record will be written for a 
single Write order. For devices like the card punch, if 
fewer than a standard number of bytes are specified (80 for 
EBCDIC and 120 for binary), the remainder of the record 
is padded with blanks (EBCDIC) or zeros (binary). Most of 
the general comments which apply to MrREAD also apply 
to MrWRITE. 

Write End-of-File. Order code X'03' produces the fol- 
lowing results: 



Device 



Result 



Line Printer No effect 

Keyboard/Printer No effect 

Card Punch !EOD card 

Paper Tape Punch I EOD NL 



Magnetic Tape 



RAD 



EOF tape mark 
Logical file mark 



For devices where the Write End-of-Fite order has no 
meaning, a status of "operation not meaningful for this 
device" will be returned. If a magnetic tape or RAD file 
is positioned at the end-of-tape, the end-of-file will be 
output. (This is the only writing allowed past the end-of- 
tape when error checking is specified.) For RAD files, the 
end-of-file is set to the current record position within the 
file as determined by the most recent access through 
MrREAD, MrWRITE, or MrCTRL. 

Write EBCDIC to Keyboard/Printer. The first byte is as- 
sumed to be a carriage control byte and is never printed. 
If the byte is a zero or a one, double spacing Is used; other- 
wise, single spacing is used. In any case, this first byte 
is not sent to the keyboard/printer. Trailing blanks are 
removed and a NEW LINE code is command chained to the 
last nonblank byte of the user's buffer. If there are more 
than 85 printable characters, those beyond 85 are ignored. 

Write Binary to Keyboard/Printer. The exact number of 
bytes specified is written. No format byte is assumed, no 
editing is performed, and no line format is imposed. It is 
the user's responsibility to insert NEW LINE codes if more 
than 85 bytes are output. A maximum of 256 bytes may be 
output with one operation. 

Write EBCDIC to Paper Tape. Trailing blanks are removed 
and a NEW LINE code is inserted as the last byte (if not 
already present). The entire record, specified by the byte 
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count, is edited and output and an "incorrect length" status 
is never returned. 

Write EBCDIC to Line Printer. The first byte per record 
is always assumed to be a carriage control (format) byte, 
and is never printed. With any odd byte count (as in all 
of the I/O), the first byte transmitted is from the right 
half of the first word, and the left half of the first word is 
ignored. 

The print routine chonges the logical format byte (as shown 
below) to the proper physical format code for the printer. 
If more than 133 bytes are specified, the remainder beyond 
133 bytes is ignored and an "incorrect length" status re- 
turned. If fewer than 133 bytes are specified, the right 
(trailing) portion of the printed image will contain blanks- 
However, the user's buffer is not modified. The print rou- 
tine will first data chain on the order byte and format byte 
in the Monitor area and then on the user's print image. 

If it is desired to force single spacing, there may be a word 
appended to the beginning of the user buffer with a blank 
in the right half; the byte count is then increased to an odd 
value, and up to 132 bytes from the original buffer will be 
printed with the extra "blank" used as the format byte to 
force single spacing. The format codes (in EBCDIC) are 

Format Byte Effect 

blank No space before printing, single 

space after printing. 

1 Page eject before printing, single 

space after printing. 

Single space before printing, single 

space after printing. 

No space before printing, no space 
after printing. 

Any other format code will be treated like a blank but will 
not be printed. These are standard FORTRAN format char- 
acters with the exception of the minus sign (-) which is sub- 
stituted for the standard FORTRAN plus sign (+) to allow 
overprinting. The user can use M.-IOEX (General I/O 
Driver) to send the standard format code or any other format 
code for Xerox printers. 

Write Binary to Line Printer. Writing binary to the line 
printer is identical to writing EBCDIC to tfie line printer 
except that the first byte from the user buffer is treated as 
a pseudo VFC and is interpreted by the line printer handler 
(see Appendix F). 



Write EBCDIC to Card Punch. Regardless of the byte count 
requested, 80 bytes are always output. If fewer than 80 
bytes are requested, the punch image is filled out with 
blanks. The image is moved to a Monitor buffer; the user's 
buffer is never modified. If more than 80 bytes are re- 
quested, only the first 80 are output and the surplus is 



ignored. In this case, "incorrect length" status is returned. 
If the file has been declared BCD at system initialization, 
all EBCDIC output records are converted to BCD before 
being punched. (The operation is performed in the Moni- 
tor's buffer. ) 

Write Binary to Card Punch, Regardless of the byte count 
requested 120 bytes are always output. If less than 120 
bytes are requested, the punch image is padded with 
trailing zeros. (The image is moved to a Monitor buffer; 
the user's buffer is never modified. ) If more than 120 bytes 
are requested, only the first 120 will be output and the 
remainder ignored. In this case, an "incorrect length" 
status is returned. 

Write EBCDIC or Binary on Magnetic Tape. Variable- 
length records are possible; no check is made of the data 
and no editing is performed. The exact byte count (up to 
the allowable maximum) is always written, however for 
reliability reasons, it is recommended that byte counts less 
than twelve or greater than 8190 not be used. For 7-track 
magnetic tape, the data is recorded in either BCD or 
packed-binary format, which may cause an "incorrect 
length" status if the record is not read with the same byte 
count used to write the record (see the 7-Track Magnetic 
Tape System Reference Manual, Publication 90 09 78). No 
"incorrect length" status is ever returned. 

If the tape is positioned past the end-of-tape marker and 
error checking is specified, the data is not transmitted and 
"end-of-tape" status is returned. If error checking is not 
specified, the data is transmitted and the "end-of-tape" 
status is not returned . 

If the tape is physically write-protected and an "initiate 
no-wait" order is requested, the "write-protected" status 
is returned. If an "initiate and wait" order is requested, 
the Monitor puts out an alarm and waits for operator action 
(see the pseudo order bytes under the definition for ORDER 
under word of the argument list). 

Write EBCDIC or Binary on Sequential RAD Files. When 
writing on blocked files, a blocking buffer must be sup- 
plied. If the calling program has not specified a blocking 
buffer, M:WRITE will call MiOPEN to reserve space in the 
task's buffer pool. If no buffer is available, M:WRITE exits 
with a "blocking buffer unavailable" status. 

Records to be written on compressed files are edited with 
compression codes inserted in a Monitor buffer. The data 
in the user's buffer remains unchanged. 

For Compressed files only, the logical record size has no 
meaning and the requested number of bytes is compressed 
and output. For all other files, a byte count less than, 
equal to, or greater than the logical record size can be re- 
quested and the requested number of bytes, up to the maxi- 
mum of the logical record size, is always output. If the 
byte count is greater than the logical record size, an "in- 
correct length" status is returned. In any case, the file is 
positioned to the next logical record regardless of the byte 
count transferred. 
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An "end-of-tape" stafus is returned when the file is 
positioned at the logical EOT (whether error checking is 
specified or not or if the current operation will cross 
the logical EOT). Data cannot be output past a logical 
EOT. 

If a Write is attempted on a file that is either logically 
write-protected or on a RAD track that is physically write- 
protected, a "write-protected" status is returned and no 
data is output. 

Since the RAD has no read-after-write capability as do 
magnetic tapes, a separate Check-Write operation is essen- 
tial to ensure absolute validity of the data output. How- 
ever, since a separate Check-Write operation requires as 
much time as the original write operation, and the RAD has 
a high degree of reliability, the capability should only be 
used when the data is sensitive or cannot be regenerated. 
Backspacing operations must be performed before the Check- 
Write operation, since no repositioning is performed at this 
time. For compressed or blocked files, no Check-Write is 
allowed and a status of "operation not meaningful" will be 
returned. 

Write EBCDIC or Binary on Unblocked Random-Access RAD 
Files. Although a granule size may be specified when a 
random file is defined, the size does not retrict the maxi- 
mum number of bytes that may be written. However, each 
Write operation begins at the start of a granule, and 
uncompleted granules are filled out with zeros. The exact 
number of bytes requested is output; never with "incorrect 
length" status return. If the Write begins or extends beyond 
the file's ending boundary, no data is transmitted and an 
"end-of-tape" status is returned, whether or not error 
recovery is specified. 

If a Write Is attempted on a file that Is either logically 
write-protected or on a RAD track that Is physically write- 
protected, a write-protected status is returned and no data 
is output. 

Write EBCDIC or Binary on Blocked Random-Access RAD 
Files. Any access is restricted to the record size regardless 
of whether the access is random or sequential. Incorrect 
length and end-of-tape may occur. Write protection con- 
siderations are the same as for unblocked random files. 

Note; For all disk files, no transfer will be initiated 
that will cross a track boundary. Instead, it will 
be broken into two transfers: one to write to the 
end of the track, and a second to complete the 
transfer. Therefore, In a "no-wait" operation, a 
check must be requested to complete the transfer. 
If an AIO Receiver Is specified, it will be entered 
each time channel end occurs, but it also must be 
specified in each check operation call which may 
be different from the AIO Receiver given In the 
Write call. 



When using M:WRITE to make requests on a Logical Device 
(refer to chapter 5 - I/O Operations for description of 



Logical Devices), where Logical Device Is used In the sense 
of a mechanism to facilitate information transfer between 
tasks independently of real devices, the following observa- 
tions should be made: 

1. Channel timeout does not apply. 

2. Check Write Is not meaningful. 

3. Write Binary and Write EBCDIC are not differentiated. 



M:CTRL 



(General Control Routine) 



M:CTRL provides desvlce-lndependent positioning capoblll- 
ties for magnetic tapes (both 7-track and 9-track) and for 
RAD files. All M:CTRL control functions are exempt from 
channel time limits. The calling sequence is 

LDX adrtst 

RCPYI P, L 
B M:CTRL 

where adrlst is the pointer to the argument list which Is 
a set of two or five consecutive words either in the user's 
program or in a temporary stack. This argument list appears 
OS follows. 

word 



F 


A 


W 





iR 





D 


Order 



1 2 3 4 5 6 7 8 



15 



where 
F 



= 1 If a device-file number is specified. 

= if an operational label or device unit number 

is specified. 

= 1 if an AIO Receiver is specified In word 4 
(specifiable by foreground only). 'A' is 
ignored if 'W' = 1. 



= If no AIO Receiver is specified. 

W = 1 if wait for completion is unconditional, 

= If wait is only for "initiate and return", 
return Is immediate If the operation can- 
not be started Immediately. 

If the Order is "Check previous output for completion (04)", 
the 'R' Is used as follows: 

R = do not retry the operation if Operator Inter- 
vention is required; instead, return "Opera- 
tor Intervention Required" . 

= 1 retry the operation, notifying the operator If 
Intervention is required. 
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') = 1 indicates that the device has been marked 

"down" by a DU key-in. 

= indicates that the device is not down, 

I/O may not be performed on a "down " de- 
vice unless bit 7 of the request order word is 
a one; otherwise, device-unavailable status 
is returned. Similarly, l/O may not be per- 
formed on an "up" device unless bit 7 of the 
request order word is a zero. 

The D bit is intended for the use of RBM di- 
agnostic programs to allow testing of failing 
devices. User programs should code with the 
D bit reset (D = 0), 

ORDER is one of the following pseudo order bytes: 

Order Operation 

X'04' Check previous operation for com- 

pletion (after a "no wait" initiation) 

X'EB' Space Record Backward 

X'EF' Space Record Forward 

X'FB' Space File Backward 

X'FF' Space File Forward 

X'2B' Rewind Off Line 

X'3B' Rewind On Line 



word 1 



Operational label or file number 



15 



Return is to the location in the L register. The B register is 
always saved. Status is returned in the E, A, and X regis- 
ters, as in M:READ. No wait initiate requests must be 
followed by a check operation. Otherwise, subsequent 
requests on this file will result in a calling sequence error. 

Note: For compressed RAD files, where these operations 
are not meaningful, an "operation not meaningful" 
status will be returned. 



M:CTRL FUNCTIONS 

If the device is a magnetic tape or a RAD file, it is posi- 
tioned as indicated. The record spacing commands ore uti- 
lized for physical records and are not meaningful for 
FORTRAN logical records. 

Space Record Backward. The Space Record Backward order 
positions a magnetic tape to the start of the previous physi- 
cal record. If the tape is already at load point, the order 
is ignored and a BOT status is returned. If the previous 
record was an end-of-file, EOF status is returned. 

For compressed RAD files, this order is illegal and a 
status of "operation not meaningful for this device" will 
be returned. 

For all other RAD files, the file is positioned to the start 
of the previous logical record. If the file is positioned at 
the logical BOT, the order is ignored and a BOT status is 
returned. If the file is positioned immediately beyond 
the logical EOF, EOF status is returned and the file is 
repositioned to the point immediately before the logical 
EOF. If the file is blocked and there is output data in 
the blocking buffer, it is written on the RAD before the 
file is repositioned. 

Space Record Forward* The Space Record Forward order 
positions a magnetic tape ot the start of the next physical 
record. If the record skipped was an end-of-file, EOF 
status is returned. 



Words 2 and 3 are currently unused and should be coded 
as zeroes. 

word 4 



AIO Receiver Address 



If A = I (in word 0) and 'W / 1, this is the address of the 
closed AIO Receiver subroutine entered by the l/O interrupt 
task when the associated tape motion is complete. 

Note; In certain cases, an l/O interrupt will not occur 
and the AIO Receiver will not be entered. When 
such a situation exists, M:CTRL will return with 
the '.X' register set to -1, as for M:READ/M: WRITE 
functions. 



For compressed RAD files, this order is illegal and a 
status of "operation not meaningful for this device" will be 
returned. 

For all other RAD files, the file is positioned to the start 
of the next logical record. If the record skipped was the 
logical EOF, an "end-of-file" status is returned. If the 
file is positioned at the logical EOT, the record is not 
skipped and an "end-of-tope" status is returned. 

Space File Backward. The Space File Backward order posi- 
tions a magnetic tape to either the start of the previous file 
mark (and EOF status is returned) or load point (if there is 
no file mark). If the tape is already at the load point, the 
order is ignored and BOT status is returned. 

For RAD files, the file is positioned to either the start 
of the logical EOF or to the logicdJ BOT. If the file 
is positioned immediately beyond or at the logical EOF, 
it is repositioned to the point immediately before the 
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logical end-of-fife, and EOF stafus Is refurned. If the 
file is positioned before the logical EOF, it is repositioned 
to the beginning-of-tape and BOT status is returned. If the 
file is already positioned at the logical beginning-of-tape, 
the order is ignored an6 BOT status is returned. If the file 
is blocked and there is output data in the blocking buffer, 
it is written on the RAD before the file is repositioned. 



Space File Forward. The Space File Forward order positions 
a magnetic tape to the start of the next file. A status of 
EOF is returned. 



For RAD files, the file is positioned immediately at the 
logicol EOF and "EOF" status is returned. If the file 
is already positioned beyond the logical EOF or no logi- 
cal EOF has been written, the order is ignored and an 
"illegal RAD sequence" status is returned. If the file is 
blocked and data has been written in the blocking buffer, 
it will be written out before the file is repositioned. 



Rewind On-Line. The Rewind On- Line order rewinds mag- 
netic tape to the load point. If the tape is already at the 
load point, no error status is returned. 



For RAD files, the file is positioned to the logical BOT. 
If the file is already ot the load point, no error status 
is returned. If the file is blocked and there is output 
data in the blocking buffer, it is written on the RAD before 
the order is executed. 



Rewind Off-line. For magnetic tape, the tape is rewound 
and unloaded. The Rewind Off-Line operation is useful 
for a "save" tape or for a tape at the end-of-reel when a 
new tape must be mounted. The user must control and check 
this condition. 

For RAD files, the file is closed by a call to MrCLOSE. 
If the file is blocked and there is output data in the 
blocking buffer, the data is written on the RAD before 
the order is executed. In addition, the file directory 
is updated on the RAD to reflect the current position of the 
logical file mark. 



M:DATIME 



(Calendar Date and Time of Day) 



MrDATIME provides the calendar date or time of day, or 
both, to either foreground or background programs in 
EBCDIC format. The calling sequence is 



LDX 



adrlst 



RCPYI P,L 

B MrDATIME 

where adrlst is the pointer to the argument list, which is a 
set of two consecutive words either in the user's program 



or in a temporary stack. This argument list appears as 
follows: 

word 



D T S O 



1 
where 
D 



O 



2 3 15 

= 1 if return calendar date is specified. 
= if calendar date is not required. 

= 1 if return time of day is specified, 
= if time of day is not required, 

= 1 if date and time are supplied by the user (in 
Address and Address + 1), 

= if current date or time of day, or both, are 
to be used. 

= 1 if date and time are to be unconditionally 
solicited from the operator. 

= if current date or time of day or both are to 
be used. 



word 1 



Address 



15 

where Address is the location where the date and time of 
day are stored. 

Return is to the location in the L register. The B register is 
always saved. 

MrDATIME FUNCTIONS 

KiCLOCK in the communication region is a pointer to the 
accounting table that contains the date and time. The date 
and time are set at system initialization and can be reset 
by the operator through unsolicited key-ins. The date is 
automatically advanced (if Clock 1 or JOBACCT is indi- 
cated) and provisions are included for year changes includ- 
ing leap-year adjustment. Thus, under continuous opera- 
tion, only adjustments to accommodate daylight savings 
time changes are required. The date or time of day, or 
both, are stored in the following format in the area of core 
specified by word 1 of the argument list: 



Date: 



Time: 



M 


M 


^^^^ 


D 


D 


^-^^ 


Y 


Y 


A 


A 


H 


R 


M 


N 



2 blanks are sup- 
plied when both 
date and time are 
requested 



Note: Time of day is given in military time (0000-2359). 
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If the date and the time ore supplied by the user (S = 1), 
the times supplied in Address and Address + 1 will be over- 
laid by the calendar date or time, or both. This option is 
used by the Job Control Processor 'PURGE command. 

If O is specified, the date and/or time will be solicited 
from the operator. 



M:TERM 



(Normal Exit from User Programs) 



M:TERM provides an entrance bock to the Monitor on a nor- 
mal termination of a user program. The calling sequence Is 



RCPYI 
B 



M:TERM 



M:TERM FUNCTIONS 

For an unload request, M:TERM triggers the RBM Control 
Task routine S:LOAD for the next load if any other entry 
is in the queue stack. If no additional requests are present 
and S:LOAD has checkpointed the background, S:LOAD 
triggers RBM Control Task S:REST for a restart. Foreground 
blocking buffers are not closed. A call to M:CLOSE is 
required before calling M:TERM to guarantee that blocking 
buffers are correctly merged with RAD files. If the call is 
from a real-time foreground program, the task is disabled 
and M:EXIT is called to perform the exit functions. If the 
calling task occupies nonresident foreground, an unload 
operation is performed. 

On calls from the background the L register must be set to 
a background addressorthe background call will be aborted 
with a protection violation. All l/O is allowed to run 
down. All files utilizing blocking buffers will have their 
blocking buffers closed out. If an unconditional post- 
mortem dump was specified, it will be performed at this 
time. The Control Command Interpreter will then be read 
into the background and wll 1 read the next control command. 



MlABORT (Abort Routine) 

When a background program fails for any reason, a call to 
M:ABORT provides a method of clearing the background 
program out of core memory and for terminating all active 
I/O for the background program. The calling sequence is 



LDA 



LDX 



loc 



code 



RCPYI P,L 

B M:ABORT 



Return is never to the location in the L register. If the 
call is from a real-time foreground program, the task is 
disabled and M:EXIT is called to perform the exit functions. 
If the calling task occupies the nonresident foreground area, 
an unload operation will be performed. On calls from the 
background, the L register must be set to the background 
or the background call will be aborted with a protection 
violation. All I/O in progress is allowed to complete and 
a postmortem dump will be performed at this time if pre- 
viously requested. 



M:SAVE 



(Interrupt Save Routine) 



M:SAVE routine performs the full context switching when 
a foreground interrupt occurs. It is available only for fore- 
ground programs that are connected directly to an interrupt. 
The calling sequence is 



RCPYI 



ADRL 



P,L 



M:SAVE 



tcb 



where tcb is the address of the Task Control Block for the 
task. 

Return is to the value in the L register + 1. The contents 
of all registers except A and L are transferred to the TCB. 



M:SAVE FUNCTIONS 

The contents of A and L must be saved in the proper place 
in the TCB before the task calls MrSAVE. MrSAVE then 
saves the original value of X, T, B, and E in the TCB. The 
interrupting task has its own floating accumulator set into 
locations 0001-0005 and the previous task's floating ac- 
cumulator pointers are saved. The MrSAVE routine stores 
the temporary stack and TCB pointers in locations 0006 and 
0007 for this current task and saves the old values in the 
interrupting task's TCB, 

If the flag in the TCB is set for "no temporary storage" 
M:SAVE saves only the hardware registers and the TCB 
pointers, and not the full context. 

If JOBACCT has been specified, M:SAVE will switch 
charges to foreground at the first interrupting foreground 
task. 

An additional entry point, M:FSAVE, is available for users 
of the Store Multiple instruction^ This entry point, with 
an address literal in cell X'C7', assumes that all registers 



where code is a word of EBCDIC information and loc is a 
word of hexadecimal information that is printed on the DO 
and OC devices to show why the job was aborted. 



Store Multiple is a standard feature on Xerox Model 530 
and is an optional feature on Xerox Sigma 3 computers- 



Service Routines 49 



have been saved, but performs the remainder of the functions 
of M:SAVE as listed above. The calling sequence is 

RCPYI P,L 

B *X'C7» 



ADRL 



tcb 



where tcb is the address of the Task Control Block for the 
task. 



M:EXIT 



(Interrupt Restore Routine) 



M:EXIT restores the contents of all registers prior to exit 
from a foreground task, switches the full context back to 
the previous task, and performs the actual exit sequence. 
The calling sequence is 



RCPYI 



B 



P,L 



M:EXIT 



Return is to the interrupted task at the address saved in the 
PSD. All registers are restored to the same value they had 
at the time of the interruption. 



M:EXIT FUNCTIONS 

The operations perfornned by MrEXIT are essentially the re- 
verse of those in M:SAVE. It is necessary to inhibit inter- 
rupts for about 1 1 microseconds for the actual exit sequence, 
but it is not necessary to call M:EXIT to perform the exit 
sequence if it can be performed by the user's program. 

The TCB contains a flog to indicate whether any temporary 
storage is used. If the task does not use any Monitor I/O 
routines or the floating accumulator, no temporary storage 
is needed. In this case, only the hardware registers are 
restored. M:EXIT will restore charges to background if 
JOBACCT has been specified and return is to background. 



M'.HEXIN 



(Hexadecimal to Integer Conversion) 



The M:HEXIN routine converts a hexadecimal number (rep- 
resented in EBCDIC) to a binary integer. The calling 
sequence is 



LDA 



left 



RCPY A,E 
LDA right 

RCPYI P, L 



B 



M:HEXIN 



where left and right contain the EBCDIC codes for the hexa- 
decimal number (the left and right part of a possible four- 
byte field). 



Return is to the location in the L register. The result is in 
the A register, the X register is changed, and the B register 
is unchanged. 



M.-HEXIN FUNCTION 

Blanks and zeros are treated as hexadecimal zeros. No tem- 
porary storage is used and no error checking is performed, 

M:1NHEX (Integer to Hexadecimal Conversion) 

The M:INHEX routine converts a binary integer to a hexa- 
decimal representation in EBCDIC code. The calling se- 
quence is 

LDA integer 

RCPYI P, L 

B M:INHEX 

where integer is the value to be converted. 

Return is to the location in the L register. On return, the 
E register contains the leftmost two bytes, and the A regis- 
ter contains the rightmost two bytes. The X register is 
changed, but the B register is unchanged. 

M:INHEX FUNCTION 

Four fields of four-bit hexadecimal codes are converted to 
four fields of eight-bit EBCDIC equivalents. No temporary 
storage is used. 



M:CKREST 



(Checkpoint/Restart Background) 



M:CKREST checkpoints the background (i.e. , writes it out 
into a predefined area on the RAD), turns the background 
space over to the foreground program, and then restarts the 
background when requested. The calling sequence is 



LDX 



ad r I St 



RCPYI P, L 

B MrCKREST 

where adrist is a pointer to an argument list, as follows: 

word 



G R P 







12 3 15 

where 

C = 1 if request is to "checkpoint" the background. 
= if request is to "restart" the background. 
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- 1 if a Checkpoint Complete Receiver is to be 
informed when the checkpoint is complete. 
(Valid only if C = 1 and P = 0.) 

= if no Checkpoint Complete Receiver is used. 

= 1 if checkpoint is to be performed at the level 
of the calling task (meaningful only if C == 1). 

= if checkpoint is to be performed at the level 
of the RBM Control Task (meaningful only if 
C = l). 



word 1 



Checkpoint Complete Receiver 







15 



The Checkpoint Complete Receiver should be used like 
an AIO Receiver. That is, after requesting a checkpoint, 
the foreground program should release control by a call 
to M:EXIT and regain control through the specified re- 
ceiver address when the checkpoint operation is com- 
pleted. Only a foreground program can checkpoint the 
background; a background program cannot checkpoint the 
background area. 

Return is always to the location contained in the L register. 
The B register is always saved. The A register contains the 
status (1 if operation is impossible; if successful). 



M:CKREST FUNCTIONS 

Checkpoint- All active I/O for the background is allowed 
to complete but no error recovery is performed for this I/O 
until the background is restarted. Peripheral devices dedi- 
cated to the background should not be repositioned. 

When all I/O has terminated, the entire background space 
is written out onto a prespecified area of the RAD and the 
background is set "protected". If the background is truly 
"empty"*" when the request is made, the checkpoint is per- 
formed immediately, and no RAD is required for the check- 
pointing procedure. If a Checkpoint Complete Receiver 
was specified, it will be entered with the L register set to 
the return address and will be run at the RBM Control Task 
level. 

A checkpoint operation will be automatically perfor^ned 
while loading a nonresident foreground program that ex- 
tends into the background. When the active nonresident 
program unloads (see Monitor service routine M.-LOAD), 
the background will be automatically restarted. When the 
checkpoint operation is completed, the message !!BKG 
CKPT is output to inform the operator. 



This would occur after a IFIN command was encountered 
or when the Monitor was in an idle state after an abort of 
an attended job. 



Restart. A restart is always performed at the priority level 
of the RBM Control Task. It is assumed that no peripherals 
have been repositioned. The core allocation table is re- 
stored to the previous value before the checkpoint took 
place, and the background is then loaded in from the RAD 
and continues as before. 

If no background program was in progress when the check- 
point was called for, the background is set to an unprotec- 
ted status but no attempt is made to reload a program from 
the RAD when the foreground terminates. 

The message ! IBKG RESTART is output to inform the opera- 
tor that the background has been released by the foreground. 
See Chapter 6 for more details. 



M:LOAD 



(Absolute Core Image Loader) 



M:LOAD initiates the loading of the root segment of a resi- 
dent or nonresident foreground program by entering the re- 
quested program name into the queue stack. It also initiates 
the loading of the root segment of a resident or nonresident 
foreground program or background processor upon request 
from the Job Control Processor, or from a background pro- 
gram that desires to load and transfer control to another 
background program. M:LOAD is also used to release (un- 
load) the nonresident foreground space for use by the next 
program in the queue. 

The calling sequence is 



LDX 



adrlst 



RCPYI P,L 

B M:LOAD 

where adrlst is a pointer to an argument list, as follows: 
word 



QUO 







1 
where 



2 3 
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Q 



1 indicates a request to read from the specified 
device-file number (word 1). The device- 
file number must currently be assigned to a 
RAD file. (This option is restricted for use 
by the Job Control Processor. ) 

indicates a request to read the specified pro- 

gram from the user's processor (UP) RAD area. 
The program name is given in C1-C8, 

1 indicates the request is to be queued if it can- 

not be satisfied now (meoningful only for fore- 
ground loads). 

indicates the-^request is to be ignored if it can- 
not be satisfied now. 
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1 indicates an unload operation, in which case 
P and Q are not meaningful. 

indicates a load operation. 



word 1 



DFN or CI and C2 




word n 



15 



C7 


C8 







7 8 



15 



where 

DFN is the device-file number. 

C1-C8 is the program name (must be 8 characters, 
including trailing blanks; program must reside in 
the UP area). 

For foreground loads, return is always to the location in 
the L register. The contents of the B register are always 
saved and the A register contains status codes, as follows: 

A Register Meaning 



Operation is successful. 

Request cannot be honored at this time 
(this could occur if Q = and a non- 
resident foreground area was already 
committed; or if Q = 1 and the queue 
stack was full). 



MrLOAD FUNCTION 

After saving the nonresident program name or device -file 
number request, M:LOAD triggers the RBM Control Subtask 
S:LOAD and then exits to the location in the L register. 

The actual loading of the program is accomplished at the pri- 
ority level of the RBM Control Task. S:LOAD will ensure 
that sufficient blocking buffers are available for those oper- 
ational labels contained in the header record 'of the proces- 
sor. If the request was for a nonresident foreground program 
that extends into area reserved for the background, S:LOAD 
automatically causes the background to be checkpointed. 

If the request is from a background program, a load and 
transfer control operation is assumed. Blocking buffers 
from the current blocking buffer pool will be closed. All 
operational labels except PI will retain their current assign- 
ments. The contents of COMMON and CCBUF will be 
retained. The X register, upon transfer to the new back- 
ground program, will point to CCBUF; all other registers 
are volatile. Operational label PI will be assigned to the 
new task for S EG LOAD operations. 



It is essential that each nonresident program executed in 
the nonresident foreground area terminate itself by a call 
to MrTERM to unload, disable itself, and then exit via 
the normal interrupt exit routine (MrEXIT). This will re- 
lease the nonresident foreground area for subsequent loads. 
An unload request is an implied call to M-.TERM and is an 
alternate way of terminating a nonresident foreground task. 
M:LOAD will return an error if the calling task is not the 
nonresident foreground task. 

For an unload request, M:TERM triggers the RBM Control 
Task routine S:LOAD for the next load if any other entry is 
in the queue stack. If no additional requests are present 
and S:LOAD has checkpointed the background, SrLOAD 
triggers RBM Control Task S:REST for a restart. 

Note that M:LOAD inhibits interrupts for a short period 
while manipulating the queue stack (less than 100 psec if no 
more than eight entries are waiting in the queue). 



M:OPEN (RAD File Open) 

M: OPEN reserves a blocking buffer from a buffer pool or a 
specified location, for a blocked, compressed, or packed 
RAD file to which on operational label or device unit num- 
ber had previously been assigned. 

The calling sequence is 

LDX adrlst 

RCPYI P,L 

B M:OPEN 

where adrlst is a pointer to the three-word argument list 
shown below. 

word 



F B 



1 2 
where 



15 



= 1 if a device-file number (DFN) is specified (in- 
ternal Monitor calls only). 

= if an operational label or device unit number 
is specified. 

= 1 if a blocking buffer location is included in 
this call. 

= if no blocking buffer location is included, in 
which case M:OPEN attempts to find space 
in the task's buffer pool (see "Blocking Buf- 
fers", Chapter 5). 



word 1 



Operational label, device unit number, or DFN 



15 
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word 2 



1 if the device-file number is to be released. 



Address of blocking buffer (optional) 







15 



Return is to the location in the L register. The B register 
is restored. The following status information is contained 
in the A register on return. 

A Register Meaning 

Operation successful. 

1 Blocking buffer already defined. 

2 No space available in buffer pool. 

3 Illegal operational label or operational 
label unassigned. 

4 Not RAD file, or not a blocked RAD file. 

5 Blocking buffer outside of background for 
a file assigned to the background. 

6 Illegal DFN. 



= if the device-file number and operational 
label remain assigned but the blocking buf- 
fer is to be released (the file is not to be 
repositioned). 

= 1 if a buffer is specified. 

= if no buffer is specified. 



word 1 



Operational label, device unit number, or DFN 
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word 2 



Buffer location (optional) 







15 



MrOPEN FUNCTION 

The address of the blocking buffer (either the one specified 
or one located from the task's buffer pool established by on 
ABS or $BLOCK command) is stored in the RAD I/O Con- 
trol Table. If no open request has been performed for a 
blocked, compressed, or packed file by the user's program, 
M:R£AD, MrWRITE, or M:CTRL will call MzOPEN to allo- 
cate a buffer from the blocking buffer pool on the first data 
transfer operation. 



M:CLOSE 



(RAD File Release) 



M:CLOSE releases a RAD file (including the blocking buf- 
fer if any) or releases the blocking buffer for a blocked file, 
but retains the file assignment. In either case, partially 
filled blocking buffers are written onto the RAD. The call- 
ing sequence is 



LDX 



adrlst 



RCPYI P,L 

B M:CLOSE 

where adrlst is a pointer to the argument list, as follows: 
word 



F R B 



12 3 
where 



15 



1 if a device-file number is specified. 

if an operational label or device unit number 
is specified. 



Return is always to the location in the L register. The B reg- 
ister is always restored to its former value. The A register 
contains one of the following completion status codes. 

A Register Meaning 



Successful. 
Illegal DFN, 



The operational label is not assigned 
to a RAD file. 

Illegal operational label. 

I/O error writing blocking buffer or 
EOF onto RAD, 

No buffer available to complete the 
close operation. 



MiCLOSE FUNCTIONS 

If the file is blocked and data has been written on it, 
the contents of the blocking buffer are written onto the 
RAD. 

If the blocking buffer was allocated from the task's buf- 
fer pool, the buffer is released. The EOF is written on 
the RAD. 

If R = 1, F = 0, and the operational label has a permanent 
assignment, the label is set to that value. If the label has 
no permanent assignment, the label is deleted from the 
table of operational labels. 

If an EOF has been written on the file It must also be 
written onto the RAD. To accomplish this, M:CLOSE 
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requires a buffer into which the file directory is read. If 
no buffer is specified, MrCLOSE attempts to allocate a 
buffer from the task's buffer pool (or will use the one al- 
ready opened for this file if it is blocked). If no buffer is 
available and an EOF is to be written, the file is not 
closed and an error completion code is returned. 

If a file to be released happens to be last allocated in the 
Background Temp area (BT), its space will be recovered. 
Therefore, if BT files are closed in the reverse order from 
which they are allocated. Background Temp space may be 
recovered. 



M:DKEYS 



(Read Data Keys Routine) 



MrDKEYS provides a means for background programs to read 
the data keys on the processor Control Panel. The calling 
sequence is 

RCPYI P,L 

B M:DKEYS 

Return is to the location in the L register. The contents of 
the B register are always saved. The contents of the data 
keys are in the A register on return. 



M:WAIT 



(Simulated Wait Instruction) 



M:WAIT provides a means for background programs to 
execute a Wait instruction from nonprotected memory. The 
calling sequence is 

RCPYI P,L 

B M:WAIT 

The return is to the location in the L register. The B reg- 
ister is always saved. The return does not take place until 
the operator performs an unsolicited S key-in. 

The Monitor types out the message 

!! BEGIN WAIT 
and goes into a wait loop. 

Only a background program may use M:WAIT; a call from 
a foreground program results in a no-operation. 



M'.SEGLD 



(Load Overlay Segments) 



MrSEGLD loads and/or executes an overlay segment, for 
either the foreground or background, from a file previously 
prepared and saved on the RAD by the Overlay Loader or 
the Absolute Loader. 



The calling sequence is 

LDX adrlst 

RCPYI P,L 

B MrSEGLD 

where adrlst is a pointer to the argument list, 
word 



W L R 







Segment ID 



12 3 
where 



7 8 



15 



W = 1 if an unconditional wait for completion is 
specified. 

= if looding is to be initiated only; control will 
be returned to the calling program. 

L = 1 control is to be transferred to the transfer 
address (if one exists) of the segment just 
loaded, in which case the L register is not 
meaningful when the transfer occurs (valid 
onlyifW=l). 

= control is to be returned to the colling 
program. 

R =1 there is a "loading complete" receiver (mean- 
ingful only if W = 0). 



no " loading complete" receiver. 



word ] 



Operational label 







15 



The operational label is used to control the loading of the 
segment. The file must previously have been defined as a 
RAD file and set to the proper overlay program on the RAD. 
Background programs should use operational label PI. 

For the benefit of segmented foreground programs, the ini- 
tialize code (entered by M:LOAD) can assign an internal 
operational label to the foreground ML operational label. 
This internal operational label may then subsequently be 
used in calls to M:SEGLD. The foreground program may 
not use the ML operational label in calls to M:SEGLD. 

word 2 



ADRL of OVrLOAD 







15 



The symbol OV:LOAD must be declared as an external ref- 
erence and is set by the Overlay Loader to the value of the 
Overlay Loader Control Table address in core. 
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If the program is assembled in absolute form, the Absolute 
Loader will create the OV:LOAD table at the end of the 
root. Therefore the last item in the root would normally be 
an OV:LOAD EQU $. 

word 3 



Loading Complete Receiver 







15 



The Loading Complete Receiver is permissible only for fore- 
ground programs and should be used in the same way as an 
AIO Receiver. That is, after loading is initiated the fore- 
ground program should release control by a call to M:EXIT 
and regain control through the specified receiver address 
when the overlay operation is completed. 

On all calls specifying an "initiate only", a check operation 
must be performed on the operational label designated to 
determine the status of the load and to release the associ- 
ated device-file number for subsequent use. 

On entry, return is to the location in the L register if the 
L parameter in word of the calling sequence is "0"; other- 
wise, control is returned to the newly loaded segment. The 
B register is always saved. On the return, the A register 
contains status showing the completion code, as follows: 

A Register Meaning 

Operation complete and successful. 

-1 Irrecoverable I/O error (if W = 1), or 

device containing overlay is busy (if 
W = 0). 

2 Invalid call. 



M:SEGLD FUNCTIONS 

A core table of 5n + 1 words is maintained at the end of the 
user's root segment that defines the actual RAD addresses 
for the overlay segments. (OV:LOAD points to this table; 
n is the number of segments in the program.) The segments 
may be loaded in any order because of the random-access 
capability of the RAD. Using the Loading Complete Re- 
ceiver and associated procedures can achieve greater effi- 
ciency in foreground loading. 



M:DEFINE 



(RAD File Definition) 



M:DEFINE allocates a portion of the background temporary 
file area on the RAD for temporary use by the designated 
operational label or device unit number. This call is ap- 
plicable to foreground operations only if the opiabel or 
fdun has been previously assigned to a permanent RAD file. 
The calling sequence is 

LDA favaa (FORTRAN programs only) 

LDX adrlst 



RCPYI P, L 

B M:DEFINE 

where 

favaa signifies the FORTRAN associated variable 

absolute address. It is meaningful only if K = 1. 

adrlst is a pointer to a four-word argument list, 

word 



F 


WP 


T 


P 





K 


G 


S 






2 3 4 5 6 7 

J 



9 10 n 



15 



File Format Byte 



where 



F specifies the file format as follows; 

000 Blocked 

001 Compressed 
010 Unblocked 

TOO Random, blocked 
110 Random, unblocked 

WP = 11 if RBM write protection is specified. 

= 10 if foreground write protection is specified. 

= 01 if background write protection is specified. 

= 00 if write protection is not desired. 

T = 1 if the last temporary file allocated is to be 
truncated so that it will be only as long as 
its EOF. If no EOF has been written on this 
file, it will be truncated so that it will be 
only one record long. Space recovered in 
this fashion can be reused in the current 
M:DEFINEcall. 

= if no truncate is to occur. 

P = 1 if word 2 contains a number between and 
101 that specifies the percentage of remain- 
ing background temporary area to be allo- 
cated for this file. 

= if word 2 is the number of logical records to 
allocate. 

K = 1 if the A register contains the FAVAA. 

= if FAVAA is not specified. 

G = 1 if a granule size for random files is specified; 
otherwise, the granule size is determined by 
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the sector size of the reference device 
(meaningful only if F = 110). 

1 indicates the file (if packed format) may use 
the sharable blocking buffer if provided by 
the Task Control Block (see "Blocking Buf- 
fers", Chapter 5). 

indicates sharing is not desired. 



word T 



Operational label or device unit number 





where 

operational labels are EBCDIC 
device unit numbers are binary 

word 2 



15 



Number of logical records or percent 



15 



word 3 



Logical record size, or granule size if G=l (bytes) 



15 



The number of logical records in the file and the logical 
record size are used to calculate the actual temp space 
required. For compressed EBCDIC files, the logical record 
size must be less than 2047 bytes. For compressed EBCDIC 
files, n card images can normally be accommodated by n/3 
80-byte records. Thus, 12,000 card images would require 
4000 80-byte records (about 83 tracks on a 360-byte per 
sector RAD). For blocked, uncompressed files, the total 
area in sectors equals the number of records requested, di- 
vided by the number of logical records per sector. Thus, 
120-byte binary card images can be placed three per sector 
on a 360-byte-per-sector RAD. A 300-card deck would 
therefore require 100 RAD sectors (seven tracks). If G = 1 
and F = 110, the file size is computed using the granule 
size in word 3. 

If this is a random file and G = 0, then the logical record 
size is actually the FORTRAN random I/O logical record 
size and the granule size is equal to either the physical 
sector size for temporary files, or to the granule size 
defined at file ADD time for permanent files. 

For unblocked records, the total area in sectors equals the 
number of records requested multiplied by the number of 
sectors required for each record. 



Return is to the location in the L register. The B register is 
restored. The A register contains status information on the 
return, as follows: 

A Register Meaning 

Operation successful. E register con- 
tains number of records in file; X reg- 
ister contains record size in bytes. 

1 Calling sequence error. Logical record 
size is not an even number or records 
requested. 

2 Operational label invalid (foreground) 
or no spare entry in operational label 
table. 

3 No more device-file numbers for the 
RAD. 

4 RAD overflow (files too large). 

5 K =^ 1 and attempted to define pre- 
viously defined file with a different 
FAVAA. E register contains number 
of records in file; X register contains 
record size in bytes. 



MrDEFINE FUNCTIONS 

For the specified temporary file, the appropriate size is 
allocated from the pool of temporary file space if such space 
is available. An unused device-file number is then initial- 
ized with the boundary points of this RAD file. All subse- 
quent references to this file (until closed by a call to 
M:TERM, M:ABORT, or MrCLOSE) will refer to the allo- 
cated area. The file is set to the "rewound" condition, if 
it is a sequential file. 

If the operational label is already assigned, no error status 
is returned if it is assigned to a background RAD file. If 
K = 1, the address of the FORTRAN Associated Variable 
from the call must be the same as the one for the file. 

Note: M:DEFINE uses locations 1-3 (of the calling pro- 
gram's floating accumulator) for temporary storage. 



IVI:ASSIGN (Assign Operational Label) 

M:ASSIGN performs equivalence between an operational 
label or FORTRAN device unit number, and 

1. A RAD area. 

2. A file name within a RAD area. 

3. A device-file number. 

4. Another operational label or device unit number. 
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The calling sequence is 

LDX adrlst 

RCPYI P, L 

B M:ASSIGN 

where adrlst is a pointer to an argument list of two to eight 
words, as follows: 

word 



TY 







o 



0- 



1 2 3 4 5 6 7 
where 



12 13 



15 



TY = 00 if the label or device unit number is to be as- 
signed to another label or device unit number. 

= 01 if the label or device unit number is to be 
assigned to a device-file number. 

= 10 if the label or device unit number is to be 
assigned to o RAD area. 

= 11 if the label or device unit number is to be 
assigned to a file within a RAD area. 

F = if the label is a background operational label. 

= 1 if the label is a foreground operational label. 

A = 1 if the two-letter area mnemonic is contained 
in word 3; otherwise, D will specify the 
area. If A is set, D will be ignored. A must 
always be set for areas other than SP, SD, 
SL, UP, UD, UL, BT, and CP. 

S = 1 indicates the file (if packed format) may use 
the sharable blocking buffer if provided by 
the Task Control Block (see "Blocking Buffers" 
Chapter 5). 

= indicates sharing not desired. 

opt = 1 indicates that device specific options are 
present in words 3-N (meaningful only if 
TY = 00or01). 

= indicates that device specific options are not 
present. 

If TY = GO or 01 and opt = 1, then D = num- 
ber of device specific options that are pres- 
ent in word 3 to word N. Device options are 
one- to four-character EBCDIC fields, two 
words per specification, which ore left- 
justified and blank filled. D must be in the 
range < D < 7. 

If TY = 10 or 11 then D has the meaning 
given below. 



D = directory to be used: 

000 Checkpoint area (area only) 

001 System Processor area 

010 System Library area 

01 1 System Data area 

TOO Background Temp area (area only) 

101 User Processor area 

110 User Library area 

1 1 1 User Data area (UD only) 

No named files may exist in either the Checkpoint or Back- 
ground Temp areas. 

word 1 



opib (1) or device unit number (1) 







15 



where opIb (1) is the operational label or device unit to be 
assigned. 

word 2 



opIb (2), device unit number (2), DFN, or buffer address 




where 



15 



oplb (2) if present, indicates that opIb (1) will be 

assigned to the device-file number that oplb (2) is 
currently assigned to, 

DFN if present, is the device-file number that 
oplb (1) will be assigned to. 

buffer address is the first word address of a buffer 

(equal to one blocking buffer in length) that will 
be used by M:ASSIGN as temporary storage for the 
appropriate RAD area dictionary. This is mean- 
ingful only for TY = 11. 

If TY =00 or 01 and opt = 1 

words 3 and 4 



Option 1, CI 


Option 1, C2 


Option 1, C3 


Option 1, C4 



(if D = 1 or 2) 
words 5 ond 6 



Option 2, CI 


Option 2, C2 


Option 2, C3 


Option 2, C4 



(ifD=2) 
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Device specific options are represented as a one- to 
four-character EBCDIC field, left justified and blank filled. 
Note that the device specific options are meaningful only 
for certain devices. Use of an unrecognized option for a 
device results in an error return of "INVALID OPTION". 

If TY = 10 or 11, the following options are recognized for 
Model 3325/35 tape drives: 

800 For 800BPI, NRZI recoding 

1600 For 1600 BPI, phase encoded recording 

ASCI For ASCII code conversion 

EBCD For EBCDIC (ASCII code conversion 'off) 
word 3 



ClorAl 


C2 or A2 







7 8 



15 



If A (of first word of argument list) = 1, word 3 contains 
the two-letter area mnemonic, Al and A2; otherwise, 
word 3 contains the first two characters of the file name, 
as continued below: 

word 3 + A 



CI 


C2 



7 8 
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word 6 + A 



C7 


C8 



7 8 



15 



C1-C8, if present, is the name of the file to which opib (1) 
is to be assigned. That is, this file on the RAD is to be 
linked to an unassigned RAD device-file number to which 
opIb (1) is, in turn, assigned. This is meaningful only for 
TY = 11. 

Return is to the location in the L register. The B register is 
restored. The A register contains status information on the 
return as follows: 

A register Meaning 

Successful operation. 

1 Mixed opibs or device-file numbers 
(foreground to background or vice 
versa) or protection violation on buf- 
fer address. 

2 Invalid opIb or DFN. 

3 No spare entries in opIb or DFN 
tables. 



A register Meaning 

4 File name not found in designated 
directory. 

5 RAD area not allocated. 

6 Illegitimate RAD file format. 

When the A register =0, the X register will contain the 
physical record size (or sector size) for this device and the 
E register will contain the newly allocated DFN. 



M:ASSIGN FUNCTIONS 

M:ASSIGN may be called to make any of four types of 
assignments, according to the setting of TY, as follows: 

TY =00oplb (1) is assigned to the DFN to which 

opIb (2) is currently assigned. OpIb (2) must 
be the same mode (foreground or background) 
as opIb (1) (error return A = 1). A background 
program cannot assign foreground opIbs (error 
return A = 1). 

= 01 opIb (1) is assigned to the specified DFN. 
DFN must be legal, must not be a RAD DFN, 
and may not be foreground if opIb (1) is 
background. 

= 10 opibi (1) is assigned to a currently unused 
RAD DFN which, in turn, Is linked via the 
RBM Master Dictionary to a current RAD area. 
The area may then be used exactly like a RAD 
file with the following characteristics: 



Format: 



random 



Logical record size: sector size in 
bytes 

Write protection: area write- 

protect code 



BOT: 



EOF: 



EOT: 



BOT of area 



EOT of area 



= 1 1 opIb (1) is assigned to a currently unused RAD 
DFN, which in turn is linked via the RAD 
dictionaries to an individual file within an 
area (e. g. , XSYMBOL). The RAD area must 
currently be accessible (error return A = 5). 
The buffer address must be in the back- 
ground if the calling program is a back- 
ground program. 

If there are no errors, the assign will take place regardless 
of the prior status of opib (1). For TY == 10 and 11, RAD 
files are rewound (file pointer is set to BOT). For TY = 00 
and 01, the file position is unchanged. 
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M:RES 



(Temporary Storage Al location) 



M:RES allocates storage from a task's temporary stack by 
addressing the B register to the first available memory loca- 
tion of that stock. If the temp storage is to come from the 
task's associated temp stack (temp stack pointers in TCB 
words 3 (start), 4 (end) and 13 (current pointer, K:DYN) it 
is called dynamic temp. When dynamic temp is requested, 
M:RES saves the current B register, addresses B to the value 
in K:DYN (from the TCB) and sets K:DYN to K:DYN+n 
(where n is defined below). 

Monitor service routines use only dynamic temp (as shown 
in Table 7). This allows them to be reentrant (i.e., 
used concurrently by different tasks, each with its own 
unique TCB). The calling sequence to allocate dynamic 
temp is 

RCPYI P,T 

B *$+3 

DATA n 

DATA 

ADRL M:RES 



/here 



T must point to background memory if M:RES is 
being called by a background program. (Other- 
wise, a PV abort will occur). 

n is the number of memory locations to reserve. 



A TS abort will occur if insufficient space is available. 
This abort can only occur for dynamic temp allocation. 

The calling sequence for nondynamic temp allocation is 
RCYPI P,T 



B 

DATA 
NONDYN DATA 

ADRL 



^$+3 



temp Pointer to nondynamic 
temp 

M:RES 



temp 



RES 



Nondynamic temp is used traditionally by Basic FORTRAN IV 
library routines which are not in the Public Library. That 
is, Basic FORTRAN IV library routines loaded witha speci- 
fic task, for use only by that task. If one of these routines 
is to be accessed as a Public Library routine, the OLOAD 
processor will set NONDYN to zero as it adds the routine 



to the Public Library and will remove the trailing temp 
reserve. This trailing TEMP RES n must not be followed 
by data or instructions. 



M:RES FUNCTIONS 

The former B register will be saved in location 1 relative 
to the new B register. Location relative to the new B 
register will contain if nondynamic temp was specified. 
Otherwise, location will not be zero and M:RES adds the 
number of locations requested to K:DYN (i.e., increments 
the temp stack pointer) after addressing B to the former value 
of K:DYN. Obviously, locations and 1 relative to the B 
register must not be changed. Location 2 relative to B is 
eventually used as the return for M:POP and is initially set 
by M:RES to point to M.-ABORT. M:RES returns to the loca- 
tion in the T register +3 if the reserve was successful; other- 
wise, M;RES will call MrABORT with the code 'TS'. 

On return from M:RES, the calling program can set its own 
return through M:POP as follows 



LDA 



return 



STA 2,,1 

The L and X registers are unchanged on return from M:RES. 



M:POP 



(Temporary Storage Release) 



A call to M:POP is mode to release the current temporary 
storage stack (pointed to by the current value in the B reg- 
ister), restore the previous value to B, and return to the 
location specified in temp + 2. 

If the temporary storage was allocated by M:RES, the call 
must set up a return in temp + 2. The calling sequence is 



LDA 



= return 



STA 2, , 1 

RCPYI P, L 

B M:POP 

where return is the location to which return will be made 
after the stack is released. 

Register L must always be set, even for foreground tasks. 

Return is to the address specified in location 2, relative to 
the beginning of the stack being released. The location in 
the L register and the return address must be in the back- 
ground area if return is to a background program. On re- 
turn, B contains its previous value before the RES-POP se- 
quence. Assume return is made to location R; L is set to 
the value R+ 1. 
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M:POP FUNCTIONS 



I^RSVP (Reserve or Refease PeripbeFols) 



M: POP performs the opposite functfons of M:RES. If foca- 
fion retative fo the B register is zero, M:POP does rK>t 
manipulate the dynamic temp stack pointer, K:DYN. 
Otherwise, the current value of the B register is stared 
irv KrDYN. Locofiarr I relative to the B register is then 
moved to the B register (ofter 2,, 1 is set aside as the 
returre). 



MtOPFILE (Convert Operaftonaf LobeF fo Device-File 

fvfeimber) 

MrOPFILE determirtes the fife ta which a for^round or 
background operotiortaf fabel is assigned. The calling 
sequence is 

IDA type 

L0X adrlst 

RCPYI P, L 

B MiOPeLE 

where 

type is the mode of the operotionat fobet; nega- 

tive for foreground, positive for background. 

adrlst IS a pointer to the operational tabef. 

Return is to the locaf ion in the L register. The B register 
is saved and restored. The status is contained^ in the E reg- 
ister as fol lows: 

E = negotive if label is not found 
== positive if lobef is foumi 

If E is positive, the following information is provided. 
Register Contents 



MrKSVP reserves a peripheral device for foregrourKt use 
only, until the foreground votuntorify releases the device; 
or until on operator keyin releases the device 



Device-fi fe number 



lOCT entry adcfress 
Operational label table entry 



Note: This routine is used primarily by RBM and certain 
processors. It will seldom be needed by user 
programs. 



LDX 



adrht 



RCPYI P,L 

B M:RSVP 

where adrlst is the pointer to the argument tist, which 
consists of one to four consecutive words either in the iter's 
progrom or in a temporary stock. This argument list op— 
pears os follows: 

word & 



^ 


^ 


R 


D 


N 


s 


M 


" 


E)ev(ce Huirfiar 



See the chapter on SYS GEN for a discussion of the I/O 
Control Table and the Operational Label Table. 



12 3 4 5 6 7 8 15 

where 

F = I if recfuest is "reserve for foregro«*r>d". 

= if reqruest is "releose to background". 

U =1 if request is for on unconditional reserve, 
where operator intervention is not required. 

= if request is for a conditional reserve, where 
operator intervention is requir«{. 

R = I if a receiver is to be entered when the con- 
ditionol reserve is completed (only meaning- 
ful if U = or if S = !). 

= if no such receiver is to be used. 

D = if a device type is not specified. 

= I if a device type is specified (used to distin- 
guish KP40 from PT40>. 



N =0 if request specifies a device number tn bits 8- 
15 of word 0. 

= I if request specifies an operational label (con- 
tained in word 1 + R + D) which is to be used 
to determine the actual device number for a 
reserve operation. The device number upon 
a successful reserve will be returned in the 
E-register. The device nurr^er must be used 
for a releose operation since an unsolicited 
'FL' keyin may hove reassigned the opera- 
tional label. 

S =0 if nonexclusive foreground use of a background 
device is requested. It is the responsibility 
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of the user to resolve contention between 
competing foreground tasks. 

- 1 if exclusive use of the device by the request- 
ing task is desired. Since RBM knows the 
"owner" of the device, an abort or termina- 
tion of that task will cause an automatic re- 
lease of the device. Once a task has been 
granted exclusive use of that device, other 
requestors receive a "device already reserved' 
(A - -1) status if R or S = 0, or a return of 
"request is queued for that device" (A = 3) 
if both Rand S = 1. 

M =0 normal RSVP messages on OC. 
= 1 suppress RSVP messages on OC. 
word 1 



Reserve Complete Receiver (optional, R = 1) 







15 



A Reserve Complete Receiver should be used like a AIO 
Receiver; namely, after the request has been acknowledged, 
the foreground program should release control by a call to 
M:EXIT and should regain control when the reserve has been 
effected through the specified receiver address. This re- 
ceiver is entered at the priority level of the RBM Control 
Task and should return to the location contained in the 
L register. 

word 1 + R 



Device type (e.g. , KP) (optional, D = 1) 







15 



If D = 1, word 1 + R contains a device type specification 
used to differentiate a specific unit of a multiple unit de- 
vice (e.g., KP40 vs. PT40). 

word 1 + R + D 



Operational Laber (optional, N = 1) 







15 



If N = 1, word 1 + R + D contains an operational label to 
be used for the reserve operation. The actual device 
number involved will be returned in the E-register. 

Return from M:RSVP is always to the location contained 
in the L register. The A register contains status as follows: 

A = if the request is acknowledged. If F = 1 and 
U = 1 (i.e., unconditional reserve), the 
device is reserved for foreground use. If 
F =0 (i.e., release), the device has been 
released fol" background use. 

= 1 if the request is acknowledged but operator 
intervention is required. The Reserve Complete 



Receiver is entered when the operator effects 
the reserve. This is the normal response to a 
conditional request to reserve a peripheral 
device (F = 1, U = 0, R= 1). 

= 2 if the device is not associated with a back- 
ground file. Not applicable if request was 
for "exclusive" use. 

= 3 request is queued. The RXR (receiver) is 
entered when the device becomes available 
(R= 1 andS= 1). 

= 4 if the operational label isnotdefined (Reserve). 

= 5 if the operational label is assigned to zero 
(Reserve). 

= 6 RXR (receiver) not specified (F = 1, U = 0). 

= 7 if the operational label is assigned to a rota- 
ting memory device. 

= 8 operational label may not be specified for 
"release". 

= 9 device has been previously reserved as shared. 

= -1 if the request cannot be satisfied because 
the RSVP table is full or if RSVPTABL, was 
specified at SYSGEN. 



X register is significant as follows: 

X = if normal condition (i.e. , OS A ■S3). 

= -1 if abnormal condition (i.e., A < or A > 3). 
Thus, a BIX may be used to detect any error. 

The E register is meaningful only when request was to re- 
serve via operational label. In this cose, upon a success- 
ful reserve request return (i .e., X =0 and < A < 3), the 
E register will contain the actual device number. The 
device number must be specified for a release operation 
since an operational label reassignment may have token 
place (e.g., FL keyin). 



MRSVP FUNCTIONS 

Reserve. If the request is for an unconditional reserve, 
a message is output to inform the operator of the foreground 
reserve action (e. g. , II lOB-RES, tP02). 

If the request is for a conditional reserve, a message is 
output to inform the operator of the request (e, g, , ! I lOB- 
REQ, CR03). The operator should then prepare that de- 
vice for the pending foreground operation, and then re- 
serve the device by an unsolicited key-in of FR (fore- 
ground reserve; for example, FRCR03). This will reserve 
the device for foreground use. If the Reserve Complete 
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Receiver is specified, it will be entered at this point. 
Note that the dedicated interrupt location of a task 
requesting use is indicated as dil- (i.e., ! !dil-REQ, LP02). 



Release. The peripheral device can be released for back- 
ground use or the next foreground task by a call to MrRSVP 
to release the device. The peripheral device specified 
will be made available for other users or background. A 
message will be output to inform the operator of the re- 
lease action if the device is being released to background 
(e.g., I! REL, CR03). The peripheral device can also 
be released by an unsolicited key-in of BR (background 
release). Unsolicited key-ins to reserve and release peri- 
pheral devices are described in Chapter 3. 



Limitations, The reserve peripheral table will accommo- 
date only as rrrany entries as were specified at SYSGEN, 
(RSVPTABL, X where X represents the number of entries to 
be provided for and defaults to 5. 



Code / 

The maintenance of an off-line, dynamic Error Log is 
valuable in the diagnosis and correction of hardware and 
hardware/software interface problems. As a SYSGEN 
option (ERRORLOG), M:DOW is available for such log- 
ging purposes. From the user-supplied argument list, 
M:DOW will create an entry to this log occording to 
Table 10, and will add this entry to the Error Log when 
RBM becomes active. 

Note: If the Machine Fault Task makes an Error Log entry, 
interrupts will be effectively inhibited for up to 
350 microseconds. 



M:COC (Character-oriented Communications — 

SYSGEN Optional, Foreground Only) 

M:COC performs input, output, and control operations on 
a specific communication line. The calling sequence is 



M:DOW (Diagnostic Output Writer or Error Logger — 

Foreground Only) 

M:DOW is a dual-purpose service routine available only 
to foreground tasks. The function that M: DOW will 
perform is dependent upon the value of a code in word 
of the argument list defined in the calling sequence below. 



LDX 



adrlst 



RCPYI P,L 

B M:DOW 

where adrlst is a pointer to the argument list, the format 
of which is dependent upon its function code, as shown in 
Table TO. 

Return is always to the location in the L register. The B reg- 
ister is always maintained. If code = 0, status is returned 
in the E, A, and X registers. This status will be the same 
as that described for M:READ/M:WRITE. If code / 0, no 
status will be returned; i.e., E, X, and A registers will be 
unspecified. 



M:DOW FUNCTIONS 

Code = 

Multitask use of the same file may result in a conflict sit- 
uation wherein a task is urxible to output a message because 
a lower-priority task has control of the file. If such a 
condition could exist, the higher priority task should call 
M:DOW, which will wait until end-action-pending occurs, 
save all status for the lower priority task, and translate the 
M:DOW argument list to an equivalent M: WRITE call. 
Since end-action-pending occursatthe I/O interrupt level, 
this allows multitask use of the same file without affecting 
low level I/O. 



LDX adrlst Pointer to the argument list 

RCPYI P, L Set the return ad«;Iress 

B M:COC Branch to the routine 

The argument list pointed to by adrlst is as follows: 



word 




Order 


word 1 


E 


Line 


number 


Prompt character 


word 2 


Buffer address 


word 3 




Byte count 


word 4 


EOM Receiver 



1 



78 11 12 



15 



where 

Order (bits 12-15) is as follows: 

Order Operation 

Status check of line. 

1 Write n bytes, no editing. 

2 Read n bytes, no editing. 

3 Send break character (long-space). 

4 Check previous read or write. 

5 Write message of up to n bytes, edited. 

6 Read message of up to n bytes, edited. 
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Table 10. M: DOW Argument Lists 



Function 


Argument List 


Word 0/Code^ 


Word 1 


Word 2 


Word 3 


Diagnostic output 


0000 


oplcbel 


Address of buffer 


Byte length 


8000 


DFN^^ 


Error Log Entries: 
SIO Failure 


0091 


DFN^^^- 






Channel timeout 


0092 


DFN^" 


- 


- 


Spurious Interrupt 


0093 


AIO status 




Bit 6 = Overflow 
indicator 

Bit 7 = Carry 
. indicator 




I/O error 


0095 


dfn'" 


- 


- 


System startup 


0018 


- 


- 


- 


Power on 


0020 


- 


- 


- 


Version 


0022 


- 


- 


- 


Time stamp 


0023 


- 


- 


- 


EBCDIC message 


0027 


- 


Address of entry 


Byte length 


Machine fault 


OOBl 


Fault register 
contents 


- 


- 


User entry 


OOFF 


- 


Address of entry 


Byte length 


Any code other than those indicated in low-order byte is treated as a "no-operation". (The code is shown in 
hexadecimal, ) 

Identifies file/device to be written to. 

Identifies file/device involved in error (not the error file). 

User entries receive a time value in words 2 and 3 of the entry. 
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Order Operation 



7 Disconnect line (turn off data set), 

8 Connect line. 

where n = < n < 255. 

E is 1 if an end-of-message (EOM) receiver is 

specified; is if no EOM receiver is specified. 

Prompt character is meaningful on duplex lines for 
orders 6 and 8. For order 6, it is the character 
(EBCDIC) to be output before input is requested. 
This can be used to signal the operator that input 
can now begin. For order 8, it specifies the mode 
in which all communication will be handled on 
this line until it is disconnected, and it has the 
following form: 

Bit Value Meaning 

8 1 Echo all input characters. 

Do not echo. 

9 1 Translate all input from 7-bit 

ANSCII to EBCDIC, and all 
output from EBCDIC toANSCII. 

Do not translate any codes. 

10 1 Check parityon input and create 

parity on output (even parity), 

Ignore parity. 

11-12 00 Device is Model 33/35 teletype. 

01 Device is Model 37 teletype. 
10 Device is keyboard/display. 

I I Device is foreign device, and 

no echoing, editing, or trans- 
lation will be performed (over- 
rides setting of bits 8, 9, and 10). 

14-15 Communication Lines (for con- 

nect order). 

00 Full duplex (echoing accepted). 

01 Simplex — send. 

10 Simplex — receive. 

I I Half-duplex (echoing not 
accepted). 

Note: The time required to turn a half-duplex 

line from receive to transmit mode is con- 
sumed in M:COC at user-program level, 
not in the interrupt handler, RCOC, 



EOM Receiver is used like an AIO Receiver. When 

an input or output message is completed, the ap- 
propriate communications task will branch to the 
specified EOM receiver address, at the priority 
level of either the input or output external inter- 
rupt, and will show the line number (of the line 
with the completed message) in the X register. 
The user program should save this status, trigger 
an appropriate user interrupt level, and return to 
the location in the L register. All operations are 
no-wait operations; that is, the return is immedi- 
ate upon initiating I/O or performing the connect 
or status checks. Thus, the EOM receiver is ap- 
plicable only for read (2 and 6), write (1 and 5), 
and send break (3) orders. EOM receivers are 
subject to the same restrictions and precautions as 
are AIO receivers. (See Chapter 6 for a more de- 
tailed discussion of AIO receivers.) 

Note: For half-duplex lines the EOM receiver is 
activated before the EOM sequence is in- 
itiated by a subsequent "check" call to 
M:COC. 



Return from M:COC is to the location specified in the 
L register. On return, the B register remains unchanged; and 
the E, A, and X registers ore set as specified in Tables 11, 
12, 13, and 14. 

The nine possible orders that can appear in the argument 
list, and the operation for each, are described below: 

Check status of line. This operation allows the 
user to check both the logical condition of the 
line (line mode, which is one of the unique codes 
in Table 14) and the physical condition of the line 
(which is reported just as it is received from the 
hardware, as shown in Table 13). Only the line 
number is needed in the argument list. 

1 Write n bytes, no editing. If the byte count is 
odd, the first output transmission takes place from 
right of the first word, and the left of the first 
word is ignored. No end-of-message codes are 
added at the end of the message, and no trailing 
blanks or null characters are stripped off. Parity 
generation and translation from EBCDIC toANSCII 
are under the control of the specified options for 
this line. 

2 Read n bytes, no editing. A read operation is 
initiated, with no editing for cancel or character- 
delete operations, but with a search for any 
ANSCII control character. Input is terminated 
if any control character is found or if the speci- 
fied byte count is exhausted. If any Input bytes 
were received before this read request was given, 
these bytes are thrown away. The end-of-message 
character always remains in the user's input buf- 
fer, translated to EBCDIC, if specified. The 
same comments about polity apply for the write 
operations. 
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Table 1 1 . Status Returns for M:COC 



Operation 


Ma|or Status 


Action 


E 


A 


X 


All operations 


Line no. not valid 


Return 
immediately 


-1 


8 


Line no. 


Calling seq. err. 


-1 


4 


Line no. 


Line has disconnected 


-1 


2 


Line no. 


Invalid line status 


-1 


1 


Line no. 


Initiate read 
or write 


Line is busy 


Return 
immediately 





-1 


Line no. 


Successfully initiated 


Initiate and 
return 








Line no. 


Check fjrevious 
input or output 


Line is busy 


Return 
immediately 





-1 


Line no. 


Operation complete 


Clear line and 
return 





Completion 
code 


Byte count 


Connect or 
disconnect 


Successful connection 


Connect and 
return 








Line no. 


Status check 


Connected line 


Test and return 


Line 
status 


Line mode 


Line rjo. 



Table 12. Completion Codes 



Table 14. Line Mode 



A Register Value 


Meaning 



1 
2 


Successful completion. 

Parity error on some byte read. 

Break condition exists. 



Table 13. Line Status 



E Register Bits 


Meaning 


0-11 


Not used. 


12-13 


Receiver status 

00: Data set not ready (if 
data sets ore used), or 
receiver not installed. 

01: Receiver on. 

10: Receiver off. 

11: Break (long space) 
detected. 


14-15 


Transmitter status 

0-: Data set not reporting 
"clear to send" (if data 
sets ore used), or trans- 
mitter not installed. 

10: Transmission in progress. 
11: Ready to send. 



A Register Value 


Meaning 





Line disconnected. 


1 


Output mode. 


2 


Prompt character output (then 
switch to input). 


3 


Input mode. 


4 


Inactive mode. 


5 


Message complete. 


6 


EOM sequence initiated (half- 
duplex only). 



Send break character (long-space). If the line is 
in an inactive mode, the long-space is sent im- 
mediately. If the line is in a write mode or a 
read mode, the operation is terminated and the 
long-space is then sent. In the argument list, only 
the line number is meaningful. 

Check previous read or write. This operation is 
required for all read and write operations, whether 
or not an EOM receiver is specified. The user buf- 
fer remains busy until the previous operation is 
checked. The line is then set inactive and be- 
comes ready for subsequent use. This is the only 
way to determine break conditions. The return 
status is shown in Tables 11 and 12. Only the line 
number is meaningful in the argument list. 
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5 Write message of up to n bytes, edited. This 
operates like the write operation without editing 
except (1) that trailing blanks and trailing null 
characters are removed and (2) that appropriate 
control characters are added as the final charac- 
ters of the message. 

6 Read message of up to n bytes, edited. This oper- 
ates like the read without editing, except that 
ignore, backspace, and cancel operations are in 
effect for the current line; when any of these spe- 
cial characters are encountered, the proper effect 
takes place on the line and the user's buffer is 
modified accordingly. (Note that the backspace 

is an editing, or destructive, backspace; that is, 
the previous character is deleted from the user's 
buffer. ) The prompt character, if nonzero, is out- 
put prior to the read operation. (See Table 15 for 
a summary of editing operations.) 

7 Disconnect line. The send and/or receive mod- 
ules of the line are turned off, the data set is 
disconnected, and the logical status is set to 
disconnect. 

8^^ — - Gonnect line. The communication mode option 
for the line, simplex or duplex, is matched against 
. the physical structure of the line and, where ap- 
propriate, the receiver is turned on. Mode con- 
flicts are returned as invalid line status. The 
logical line mode is set to "inactive" and the 
other options are set. The connected line is 
assumed to be a dedicated line or a line that has 



already dialed-in. A user program can poll the 
lines with a "check status" order prior to logical 
connection to determine when a line has been 
physically connected (i.e. , data sets ready). 



FUNCTIONAL DESCRIPTION OF COC PACKAGE 

The COC software package manages character-oriented 
telecommunications equipment (normally Teletype-compatible 
devices) at the message level, providing translation, echo- 
ing, parity checking, and the line editing as required. It 
consists of two portions, M:COC and RCOC. 

M:COC. This is a monitor service routine that performs 
all control operations and initiates all reads and writes. 
It is part of the nonresident RBM overlay structure. 

RCOC. This is a resident foreground program, usually re- 
quiring installation modifications, that consists of the fol- 
lowing tasks and related items: 

1. An initialization routine. 

2. An input- interrupt handler connected to the input in- 
terrupt of the COC controller (7611), which translates 
and edits input characters, echoes the characters as 
required, and forms input messages. 

3. An output-interrupt handler connected to the output 
interrupt of the 761 1, which translates and transmits 
output characters and performs line formatting at end- 
of-message (character-count completion only). 



Table 15. Summary of Editing Operations 







Codes Used 


Operation 
















33/35 


37 


Character Display 


User-generated end-of-message 


CR or LF or BREAK 


NL or BREAK 


NLor INTERRUPT 


character on input, edited 








System-generated end-of- 


LF or CR (opposite of 


None for NL; 


None for NL; NL for INTERRUPT 


message character on input 


user input); 

CR and LF on BREAK 


NL for BREAK 




Attention code; used to 


BREAK 


BREAK 


INTERRUPT 


terminate input or output 








Ignore this character, except 


RUBOUT or 


DEL or 


DEL or 


after ESC 


ESC, SPACE 


ESC,SPACE 


ESC, SPACE 


System-generated characters 


CR,LF, RUBOUT 


NL, RUBOUT 


NL,5 - NULL 


on output at end-of-message 








Delete previous character 


ESC, RUBOUT 


ESCDELETE 


ESC,DELETE or EM 




(echo-" — ) 


(echo\ ) 


operation 


Delete current line 


ESC,X 


ESC,X 


ESC,XorCR,CAN 
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4. Input and output translation tables (ANSCII to EBCDIC 
and vice versa). 

5. A circular input buffer (i.e., "ring buffer"), which 
overlays the initialization routine (item 1). 

RCOC may be loaded at system boot time or as needed (in- 
stallation option). When loaded, the initialization routine 
automatically connects the COC handler tasks to their re- 
spective interrupts, establishes linkage for M:COC, initial- 
izes the COC for input, and exits. At this point, all lines 
are set to the (logically) disconnected status, ready to be 
tested, connected, and used via calls to M:COC. 



M:COC FUNCTIONS 

All line-control and read-write operations are initiated by 
means of user calls to M:COC. Once RCOC has been ini- 
tialized, all input/output requests are rejected by M:COC 
until the line is connected. If a line is dedicated (i.e., 
leased or "hardwired") or if a dial-up line has dialed in, 
only a connect (order 8) call to M:COC is required. If the 
line is to be "dialed out" (physical activation from the com- 
puter end rather than from the terminal end), an MrlOEX 
SlO-order call to the Automatic Dialing Equipment must 
precede the M:COC connect request for each line (see 
"Automatic Dialing" below for further details). 

A check-line-status (order 0) call may be issued prior to a 
connect request to check for line-operational and physically- 
activated conditions, in which cose detailed line-status and 
line-mode information is returned (Tables 13 and 14). If 
this is not done and a connect request is issued for a line 
that is nonexistant or nonoperatlonal, i.e., no send and/or 
receive module installed or receive module will not turn on 
(but whose line number is valid), the following operator's 
message is issued and an invalid- line-status major status is 
returned: 

TROUBLE LINE nn 

If the line is not physically activated, e.g., not dialed-in 
(data set not ready or not "clear to send"), invalid-line- 
status is returned also. If the specified line number is not 
a valid one, this is so reported. (The range of valid line 
numbers is determined during the assembly of RCOC.) See 
Table 11 for major-status returns. 

A successful connect call for a given line sets the logical 
line mode to "inactive", in which mode any input received 



on the line is ignored, but the line is available for I/O 
requests. Subsequent I/O operations on that line must be 
initiated sequentially with a check-previous-operation (or- 
der 4) call intervening between successive read/write calls 
(I/O requests are not queued). As each read or write 
operation is completed, the logical line mode is set to 
"message complete". At this point the line is still busy and 
can only be cleared (set to inactive) by the check-previous- 
operation call. (This call, order 4, is not required after a 
check-stotus, connect, or disconnect request. ) The check- 
status (order 0) call may be executed at any time. 



Program and Interrupt- Task Relationship. A read request 
simply sets the line mode to "input" at calling program 
level, which in turn causes the input interrupt task to accept 
input on that line and build the input message in the user's 
buffer, all at interrupt level. A write request sets the line 
mode to "output" and causes M:COC to transmit the first 
character in the user's buffer at calling program level. 
Thereafter, the output interrupt task automatically transmits 
the remaining characters, one per COC output interrupt 
(i.e., one each "output word time") until the entire mes- 
sage is sent, all at interrupt level. 

As each input or output message is completed (or otherwise 
terminated), the line is set to "message complete", line 
mode 5, and the user's EOM receiver (if present) is exe- 
cuted at the interrupt level. Normally, the receiver should 
trigger the requesting taskand (always) return via register L. 



AUTOMATIC DIALING 

If Automatic Dialing Equipment (ADE) is included, real- 
time tasks can dial a terminal and connect it to a pre- 
determined COC line for that terminal. The ADE is a 
multiunit controller that controls up to 16 dial positions 
and corresponding lines. It is connected to a dedicated 
lOP channel (additional to the COC's). 

The dialing operation can be accomplished via M:IOEX. 
A TDV order should first be issued to ensure that the dial 
position is available. Then an SIO order can be issued to 
activate the ADE and address the dial position. Any order 
byte will be interpreted as a "write". The memory buffer 
contains the number of the data set being dialed (two digits 
per word, each digit occupying the rightmost four bits of 
the byte in four-bit BCD). After the dialing procedure has 
been completed, the task should check the status of the 
COC line before attempting to send or write on it. 
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5. I/O OPERATIONS 



BYTE-ORIENTED SYSTEM 

The Monitor performs all \/0 services for the byte- 
oriented I/O system. This includes: 

Logical-to-physical device equivalencing. 

Initiating I/O requests. 

Standard error checking and retry (optional). 

Task dismissal on "wait" I/O (optiorrol). 

Software checking of background requests to preserve 
protection of foreground and Monitor. 

Optionally generating device order bytes for device- 
independent operations. 

Accepting user-generated lOCDs and device order 
bytes to provide complete control for a user's 
program. 

Using data chaining for foreground programs performing 
scatter-read or gather-write operations. 

Reading or punching cards in either BCD or 
EBCDIC. 

Positioning magnetic tapes and RAD files. 

Editing from paper tape or keyboard/printer. 

All I/O interrupt handling. 

Managing both temporary and permanent RAD 
files. 

Limiting channel active time for \/0 transfers. 

I/O INITIATION 

Whenever a task needs to initiate an I/O operation, it 
calls on the appropriate Monitor I/O routine (see Chap- 
ter 4 for complete calling sequences). These Monitor 
I/O routines are reentrant, so that a higher priority 
task may interrupt and request I/O during the initiation 
of a lower-priority task, in which case the low-priority 
task is suspended and the higher-priority task satisfied 
first. 



The channel time limits imposed by the Monitor on standard 
devices are as follows: 

AAaximum Allowable Channel 



Device Type Active 


Time (seconds) 


KP 


255 


LP 


3. 


CR 


3 


CP 


3 


MT (9 track) 


10 


PT 


* chars, x rate 


MT (7 track) 


10 


RD 7202/04 


3 


RD 7242/46 


4 


RD 7251/52 


3 


PL 


Not imposed 


LD (logical device) 


Not imposed 



END ACTION 

The chapter on Operator Communication specifies the pos- 
sible error messages. Generally, standard error recovery 
takes place when the I/O is checked for completion rather 
than on the I/O interrupt. This means that error recovery 
for the background will be processed at the priority level 
of the background rather than at the I/O interrupt priority 
level. However, there is a provision for the real-time fore- 
ground user to specify an end-action routine to be called 
when the Monitor answers the I/O interrupt. This is the 
AIO receiver address in the I/O calling sequence, and it 
is to be used only when more sophisticated end-action is 
required or when a foreground task is to be restored to active 
status at channel end. The routine is processed at the priority 
level of the I/O interrupt, so the processing should be of 
very short duration. Reentrancy in this routine is the user's 
responsibility. For example, this routine might consist of 
storing the I/O status information and then triggering a 
lower-level external interrupt through a Write Direct, where 
this lower-level task performs the actual processing. The 
end-action routine should then return to the task from which 
it originally came (by RCPY L,P). 

The form of the call to the AIO receiver is 



A real-time foreground program may acquire control of 
a multidevlce controller from background users at the 
completion of any current I/O. This technique is used 
in place of queuing. All Monitor I/O Initiation is made 
at the priority of the calling task, with background tasks 
having the lowest priority. 



LDA 

RCPYI 

B 



aiodsb 



P,L 



AIO receiver address 



(device status byte 
from AIO in bits 0-7; 
device number in 
bits 8-15) 
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The AlO Receiver routine should return to the location 
contained in the L register on the entry. All registers are 
assumed to be volatile, which means that they need not be 
saved and restored to their former contents. 



T+ie purpose of the AIO Receiver technique is to allow a 
real-time user program to be informed by RBM when chan- 
nel end occurs on a particular I/O operation. It is used 
instead of I/O queueing by the Monitor. Typically a fore- 
ground program wishing to maximize l/O and computation 
overlap will issue an I/O request with the no-wait option 
and with an AIO Receiver address specified. When the 
I/O is successfully initiated, the foreground taskexitsfrom 
the active state (by a call to MrEXIT) and is restored to 
active status at channel end by a Write Direct to trigger 
the interrupt level from the AIO Receiver. The foreground 
program must then return to the Monitor I/O routine with 
the "check" option to complete the end action on the 
file. See Chapter 6 for a more detailed discussion of 
AIO Receivers. 



Note: For transfers invoking blocked files where no 
I/O is actually performed, the X register will 
contain -1 to indicate that the AIO receiver 
will not be entered. 



Table 16. Standard Device Unit Numbers 



Device Unit 




Number 


Standard Assignment 


101 


Keyboard/printer input 


102 


Keyboard/printer output 


103 


Paper tape reader 


104 


Paper tape punch 


105 


Card reader 


106 


Card punch 


108 


Line printer 



Table 2 shows the standard background operational labels. 
The devices and functions shown indicate how the standard 
processors use these labels. Since each I/O call must specify 
a byte count, a user program can read any number of bytes 
from SI (if SI is magnetic tape, for example). The labels 
are merely a name. There is no restriction on the record 
size except as imposed by the peripheral devices. 



LOGICAL DEVICES 



LOGICAL/PHYSICAL DEVICE EQUIVALENCE 

When writing a foreground or background program in either 
Extended Symbol or FORTRAN, the user is not required to 
know the actual physical device number that will be used 
in the input/output operation. Two ways are provided 
under RBM to help the user select the input/output device 
on a logical rather than physical basis. 



The first method is the direct logical reference. The user 
can specify a device-file number in his calling parameters 
to the input/output routines, and RBM will translate this 
into an actual physical device number. There may be 
several device-file numbers pointing to the same physical 
device; however, only one device-file number is generally 
needed per device per active task in the system. Each 
device-file number can be used by only one task at a time. 
This is a necessary restriction since the I/O status is saved 
in the device-file number table in theRBMand independent 
operation by several tasks on the same device would cause 
invalid status from the separate tasks using it. 



The second method is device referencing through indirect 
logical reference. This method first assigns a device unit 
number or an operational label to a device-file number, 
which in turn is assigned to a physical device number. The 
equivalence of operational labels or device unit numbers 
and the device-file numbers is set at System Generation 
time for certain standard devices, as shown In Tables 2 
and 16. The standard assignments may be changed later by 
use of 1 ASSIGN or IDEFINE control commands. 



In addition to the foregoing use of the term "logical device, " 
"Logical Device" Is also used to refer to a SYSGEN mech- 
anism for reserving logical groups of DFNs for a combination 
of foreground and background use to accomplish information 
or data transmission between tasks without the use of any real 
physical device. (Refer to the RBM System Management 
Reference Manual for a description of the SYSGEN mech- 
anism for defining a Logical Device In this sense. ) 

Logical Devices are defined at SYSGEN via a 2-character 
mnemonic'^ (for model number), and an accompanying 
pseudo-device number (indicating a channel number, pre- 
ferably unique). The user performs reads or writes on DFNs 
(or assigned opiabels) associated with the LDs via calls on 
M:READ and M:WRITE. Two DFNs must be assigned to de- 
fine one Logical Device. Communication between fore- 
ground and background tasks is accomplished by use of the 
foreground (F)/bac kg round (B) SYSGEN option at definition 
of the LD. 

One example of possible use would be where a task receives 
data from a hardware device via standard opiabel or DFN. 
This data may be manipulated (If desired) by the task and 
passed on to another task via a pair of DFNs associated with 
the same LD. The receiving task may pass the data to a 
different LD or to a real physical device. 



The mnemonic "LD" or any other 2-character mnemonic 
other than RD or XX can be used. This mnemonic may indi- 
cate a device type the Logical Device is to represent; e.g., 
LP for Line Printer as required by the printer symbiont. 
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There are no resfrrctionsastodirectionof flow of information. 
Either DFN associated with an LD may be used to read or 
write to the other DFN associated with the same LD. Two 
DFNs must be associated with one pseudo-device number to 
define an LD. 



5. BOT(beginning-of-tape) is defined as the logical load- 
point and equals the first sector of the fife. EOT is de- 
fined as the logical end-of-tape and equals the last 
sector +T of the file. EOF (end-of-file) is defined as 
the logical file mark (which may or may not exist). 



When using an LD, an I/O operation takes place between 
the two DFNs associated with the LD. That is, an l/O 
operation is only satisfied if a read/write pair of operations 
occurs within the definition of one LD. If a task communi- 
cates with more that one LD, another task (or tasks) must 
perform the reciprocal I/O operation on the DFN of each 
of the LDs the first task performed I/O on. A pre- I/O edit 
routine for LDs satisfies the I/O operation only when each 
of the reciprocal I/O requests have been made against on 
LD, Refer to the RBM Technical Manual for further discus- 
sion of the LD mechanism. 



I RAD FILES 

The two types of RAD files available are sequential files 
and random files. A sequential file may be used like a 
single-file magnetic tape, whereas a random file may be 
used like a truly direct-access device. The capabilities 
and restrictions of each type of file are described below. 



6. Both can be positioned by ! REWIND, IFBACK, and 
IFSKIP commands. 



7. Foreground I/O requests can specify on AIO Receiver 
at channel end for physical l/O transfers. When op- 
erations involve only logical I/O transfers, the AIO 
Receiver will be ignored. A flag will be set (x = -1) 
indicating the AIO Receiver is not to be acknowledged, 
(see M: RE AD/M -.WRITE status returns). 



Operational labels can be equated to permanent files 
on the RAD, or be allocated from available temporary 
RAD space. This can be accomplished either through 
control cards or through Monitor service calls at ex- 
ecution time. 



9. When the operational label is defined or assigned to a 
permanent fife, it is automatically positioned at the 
BOT. 



Random and sequential files vary in two primary respects: 

1 . Sequential files cannot be accessed randomly; the next 
record to be accessed is the one at which the file hap- 
pens to be positioned. 



10. The transfer of any even number of bytes (to a maximum 
of 65,534) may be requested, provided that the transfer 
will not extend past the file boundary for unblocked 
files. For blocked fifes a single record is processed 
on each call . 



2. Sequential fifes can only be updated at the end. 



Random and sequential files share the following attributes: 

1 . Both are available to foreground and background tasks 
(but not concurrently). 

2. Both are available to routines M:READ, M:WRITE, and 
M:CTRL, but not to M:IOEX. 

3. Both can be blocked. The Monitor I/O routines do the 
blocking and unblocking. 



SEQUENTIAL FILES 

I. Sequential RAD files can be compressed (with blanks 
removed) if they are EBCDIC data. The Monitor I/O 
routines do the compressing and expanding but do not 
check for binary data. Compressed records are always 
blocked and of variable size; therefore the logical 
record size has no meaning except when allocating 
the file. 



4. Logical records may be less than, equal to, or greater 
than the RAD sector size. Unblocked records always 
start on a sector boundary. Therefore, if a logical 
record is fess than a RAD sector and is unblocked, the 
remaining bytes of the sector will be ignored. If a 
logical record is greater than a sector, it will occupy 
an integral number of physical sectors and the remain- 
ing bytes of the last sector will be ignored. 



2. As on magnetic tape, once a logical record or file mark 
is written on a file, any records or filemarks previously 
written beyond that point are unpredictable. 



Sequential RAD files (except compressed files) con be 
spaced forward or backward by logical records. Selec- 
ted records may be read from a blocked sequential file 
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by spacing records forward or backward^ but only 
records at the end of a sequential file should be written/ 
i.e., update in-place not permitted. 



4. As on magnetic tape, the only record that can be 
written at the EOT is the logical file mark. 



GRANULES 

While a granule is usually synonymous with a sector on a 
device, it may be defined (on a file basis) to be equivalent 
to any of the following: 

• A partial sector. 

• One sector. 

• Several sectors. 



RANDOM FILES 

1. All unblocked I/O transfers start on a granule boundary 
within a file. These granule boundaries are addressed 
as a number that represents the displacement of the 
granule from the start of the file, beginning with zero. 
A granule boundary always begins on a sector boundary 
but need not end on one (see discussion of granules 
below). 



2. When a random file is defined, the user may specify a 
FORTRAN logical record size and a pointer to the word 
where the last referenced FORTRAN logical record +1 
is stored. This information, although unused by the 
Monitor, is stored in the file and may be requested by 
executing programs or processors (such as the FORTRAN 
compiler), if necessary. 



3. Random files may not be compressed. They may be 
blocked with transfer on a logical record basis. In 
this case, the Monitor performs all blocking/deblocking 
operations. Any Write operations are really an update 
in place and unmodified portions of a block are pre- 
served. A block is not read into core if it is already in 
core from a previous operation. 



4. EOF has no meaning in random files except for file sav- 
ing, truncating, and mapping purposes. 



5. Random files (either blocked or unblocked) may be 
accessed sequentially or randomly. At the end of any 
operation, RBM automatically updates the record dis- 
placement pointer to the "next" record. The pointer 
can be "set" by any random operation, is initially set 
to the beginning of the file, and may be changed 
by M:CTRL. 



As much data as specified by the byte count will be 
transferred for the unblocked random files but only one 
record at a time will be transferred for blocked random 
files and incorrect length can occur. 



A granule always begins on a sector boundary but need 
not end on such a boundary. For example, to make the 
7204 RAD and the 7242 disk pack transfers equivalent, a 
granule can be defined to be 1024 bytes; this is then one 
sector on the disk pack and two sectors plus a fraction of 
a sector on the 7204 RAD. 



BLOCKING BUFFERS 

The RBM system allows for automatic assignment of blocking 
buffers for files of blocked, compressed, or packed format. 
The number of buffers required by a program may be speci- 
fied through the !$BLOCK control card of the Overlay 
Loader. Such buffers as will fit within unused memory 
(UMEM)of the loaded program may be allocated to a max- 
imum of 16. Size of these blocks is determined by the 
value of K:BLOCK. Use of such blocks is identified and 
maintained in the task TCB (use bits). Assignment is made 
from this pool of buffers as required explicitly through an 
MrOPEN call or implicitly through the first use of the file. 
Closing a file that uses a block from the pool will free its 
buffer for later assignment. Thus, a minimum requirement 
for pool buffers may be achieved through a Judicious open- 
ing and closing of files requiring such blocks. 

The !$BUFEND control command in conjunction with the 
!$BLOCK command will allow the foreground user to allo- 
cate an area outside his program as the buffer pool. 

The ability of more than one file to share the same buffer 
block is provided to accommodate "packed" files whose 
records may be accessed randomly and thus may require a 
fresh block with each call to M:READ/WRITE. The capa- 
bility of sharing a single buffer from the program buffer 
pool is conveyed by the l$BLOCK command as the program 
load file is generated. This capability is registered in the 
TCB as the program is loaded into memory and the first buffer 
from the pool is identified as the sharable block. Packed 
random files may be individually identified as accepting a 
shared buffer through an ASSIGN or DEFINE parameter. 
Subsequent operations with such a file must be on a "wait" 
basis since the shared buffer is freed before completing 
each read or write request. If the transfer request is not 
I/O with wait, a calling sequence error will be returned. 
This is true whether the buffer is from the buffer block pool 
or whether it is allocated explicitly (M:OPEN) within the 
program. 

A buffer block may not be shared by other than packed 
random files of the same task. 



RAD Files 71 



Records of compressed, blockieddnd packed files are treated 
as a contiguous stream of data for blocking purposes. As 
such, individual records may overlap block boundaries 
without concern to blocking procedures. 



RAD FILE MANAGEMENT 

RBM permits allocation of the RAD into the subsections 
shown in Figure 4. The exact bounds on these sections are 
computed from the size of required contents or selected by 
the user in accordance with the anticipated use of the 
system. In either case, the bounds are set during System 
Generation, and cannot be changed except by a new 
System Generation. RBM maintains directories for as many 
areas as the user specifies up to 35, plus: the Checkpoint 
area, the Background temp area, the System Library, Sys- 
tem Processor area, and System Data area. RBM also main- 
tains control of the checkpoint area. The background temp- 
orary space is allocated from control command inputs or 
from calls to M:DEFINE as requested. 

Areas need not be allocated contiguously (RAD tracks may 
be skipped between areas), and can be distributed over 
more than one RAD. One to 16 areas may be allocated on 
each RAD or disk pack. However, each area must exist en- 
tirely on a single RAD. If there is more than one RAD on 
the system, one will be designated as the RBM System RAD, 
which will receive any default areas. Any RAD with sec- 
tor available will receive a bootstrop in that area. 
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Figure 4. RAD Allocation 
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6. REAL-TIME PROGRAMMING 



FOREGROUND PROGRAMS 

A foreground program is one that operates in protected 
memory, utilizes foreground operational labels or device 
unit numbers, and has access to privileged instructions. It 
is protected from any background interference through an 
integrated hardware/software protection scheme. A fore- 
ground program may be classified as either a resident fore- 
ground program, a semiresident foreground program, or a 
nonresident foreground program, and it is important that 
this distinction be understood. 



area is adjacent to the background. If a nonresident foreground 
program is to be loaded and the length of the longest path 
(including COMMON) exceeds the size of the nonresident 
foreground area, the background is automatically check- 
pointed to allow the program to extend to the background. 
The background remains checkpointed until the nonresident 
foreground program unloads by a call to M:LOAD. When 
loaded, nonresident foreground programs may be automati- 
cally armed, enabled and (optionally) triggered; or they 
may initialize themselves through their own initialization 
routines. 



RESIDENT FOREGROUND PROGRAMS 

Foreground programs are defined as resident through the 
RAD Editor when their files are created on the user pro- 
cessor area of the RAD. They are loaded into core from 
the RAD whenever the RBM system is booted, and are either 
automatically armed, enabled and (optionally) triggered, . 
or they initialize themselves through their own initializa- 
tion routines. Once loaded into core for execution, resi- 
dent foreground programs remain resident until the RBM 
system is again booted from the RAD. 

SEMIRESIDENT FOREGROUND PROGRAMS 

Semiresident foreground programs are normally not in core 
memory. They are not read into core when the RBM system 
is booted but must be called in explicitly when needed. 
Semiresident foreground programs, when loaded, reside in 
the resident foreground area. The user must schedule the 
loading of semiresident foreground programs because the 
Monitor provides no protection against overlay or over- 
loading. When loaded, they may be automatically armed, 
enabled and (optionally) triggered, or they may initialize 
themselves through their own initialization routines. 

NONRESIDENT FOREGROUND PROGRAMS 

Nonresident foreground programs are normally not in core 
memory. They are not read into core when the RBM system 
is booted but must be called in explicitly when needed. 
Nonresident foreground programs, when loaded, reside in 
the nonresident foreground area, and the area Is then consid- 
ered "active" and is not available for subsequent use by other 
programs (Including the Monitor) until the program occupying 
this area releases it by "unloading". This feature is useful 
when a system has several nonresident foreground programs 
that have a resource allocation problem or are connected to 
the same interrupt level. The Monitor will control access 
to the nonresident foreground area, thus providing protec- 
tion against multiple loading of these conflicting programs. 

If nonresident programs are to be used, at leastK:BLOCK+17 
memory locations must be allocated for the nonresident fore- 
groundarea of core. If allocated, the nonresident foreground 



MONITOR TASKS 

The relative priorities of the separate Monitor tasks are 
given in descending order below: 

Highest Counters (optional). 

Power On Task. 

Power Off Task. 

Machine Fault Task. 

Protection Violation Task (optional). 

Multiply Exception Task (optional) . 

Divide Exception Task (optional) . 

Real-time tasks, if any, higher than I/O level. 

Input/Output Task. 

Control Panel Task. 

Counters = (optional). 

Real-time tasks, if any, lower than I/O level. 

RBM Control Task (lowest hardware level). 

Background "tasks", lower than all hardware levels. 

Although the tasks are not reentrant, they are serially re- 
usable; that Is, as soon as a task finishes processing one re- 
quest, it can immediately process another. For example, 
I/O interrupts are processed one at a time, with the highest 
priority device always processed first if several Interrupts 
are waiting, but as soon as the processing of one interrupt 
request has been completed, another request for a separate 
device can be processed. 



POWER ON TASK 

The Power On Task performs the following operations: 

• Waits for acceptable RAD status. 

• Arms and enables all RBM interrupts. 



Sigma 2/3 only . 
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Triggers the RBM Control Task to send a !! POWER ON 
message. 

Restores protection registers to failure-time contents. 

Loads and links to the Power-On receiver if specified 
in pointer location X'1A9'. If the computer is a Sigma 3, 
the X register will point to the interrupt status saved 
at Power-Off time. This data is organized as follows, 
one bit per interrupt per word as described for the 
WD-instruction register bits in the appropriate com- 
puter reference manual : 

0/ 1 : if recovery will be attempted, 3 if re- 
covery will not be attempted. 



1,1 
2,1 
3,1 



Group '0' interrupts enabled. 

Group '0' interrupts armed or waiting. 

Group '0' interrupts waiting or active. 



If the computer is a Model 530, the X register will 
point to a data area organized as follows: 

0, 1 : (Recovery will be attempted). 

1, 1: Group '0' interrupts enabled. 

2, 1: Group '5' interrupts enabled. 
3,1: Group '6' interrupts enabled. 

4, 1 : Group '0' interrupts armed or waiting. 

5, 1 : Group '5' interrupts armed or waiting. 

6, 1: Group '6' interrupts armed or waiting. 

7, 1: Group '0' interrupts waiting or active. 

8, 1: Group '5' interrupts waiting or active. 

9, 1: Group '6' interrupts waiting or active. 

• Restores status at Power-Off time and exits if the com- 
puter is a Sigma 3 with no external interrupts, or is a 
Model 530. 

• Restores context and exits if it is a Sigma 2 or there 
are external interrupts and background is active. 

If none of the above conditions are satisfied, the Power- 
On interrupt is cleared and a SYSERR is forced. 

Since Power-On processing is installation dependent and 
correct recovery cannot always be guaranteed, a user- 
developed Power-On Receiver may be used to restart after 
a power failure. The following action may be taken within 
the receiver: 

1. Timeout errors will be simulated on all active I/O 
channels at Power-Off time. Code within the receivers 
may restart I/O for these devices. 

2. The interrupt status is determined, in general, through 
the TCB chain (each TCB contains the address of the 
TCB of the task it interrupted). Race conditions can 
exist that may cause this chain to inaccurately reflect 
the interrupt status, although the PSD chain is correct. 



If this risk is considered negligible or the effects 
unharmful, the tasks can be reactivated through the 
TCB chain by the receiver. 

3. The foreground Power-On Receiver may activate one 
or more foreground tasks or take other special action 
to restart the system. This may involve going to some 
recent checkpoint. 

4. The receiver may exist from the Power-On routine 
by going to M:EXIT. 



POWER OFF TASK 

The Power Off Task performs the following operations: 

• Saves all available interrupt status, depending on 
model of CPU (see above). 

• Saves context via a call to M:SAVE. 

• Scans the Channel Status Table and issues an HIO to 
any channel flagged active and saves the device status 
byte and the even and odd channel register contents in 
the File Control Table. 

• Interrogates locationX'lAS' for a Power-Off receiver. 
If one is specified, a branch is made to it; otherwise, 
the Power Off Task waits for the power-on interrupt. 

MACHINE FAULT TASK 

For Sigma 2/3 Systems: The Machine Fault task responds to 
the following Sigma 2/3 machine fault conditions, listed in 
order of priority: 

1 . Memory parity error. 

2. External lOP timeout. 

3. Incorrect direct l/O. 

4. Internal lOP timeout. 

5. Combination of conditions 2 or 3 and 4.. 



Sigma 3 only. 



Of these conditions, background can only cause a memory 
parity error. When this occurs, the Machine Fault task trig- 
gers RBM and the background task is aborted with an error 
code of PE. For all of the above conditions, including parity 
error when background is not active, an appropriate fore- 
ground receiver will be tested, as specified below. If this 
receiver pointer is zero, the action specified below will be 
taken. Otherwise, the receiver will be linked to via a 
RCPYI P, L. If the receiver returns, the Machine Fault task 
will proceed as if a receiver was not specified. The re- 
ceiver may correct the situation and simply call M:EXIT. 



Receiver 


Po 


nter 




Condition Address 






Action 


1 X 'IAD' 






Abort, code = PE 


2 X 'lAB' 






SYSERR, code = ET 


3 X 'lAA' 






Abort, code = MF 


4 X 'lAC 






Machine Fault Message 
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Abort action consists of disabling the associated interrupt 
and exiting the task. If the task occupies the nonresident 
area, an UNLOAD will be performed. If an HOP timeout 
occurs, RBM will be triggered to write the "Machine 
Fault., ."message. The active task will not be terminated 
but, on exit from the Machine Fault task, overflow and 
carry will be set to indicate device not recognized. 

All foreground abort messages and the "Machine Fault. . ." 
message will be written at the RBM Control Task level. 
Therefore, if two consecutive foreground tasks abort, only 
the message for the lower priority task will appear. How- 
ever, both a foreground abort message and the "Machine 
Fault. . . " message may accumulate. 

For Model 530 Systems: The Machine Fault Task responds 
to all Model 530 hardware-detected machine faults, as re- 
ported by the fault register. If the error-logging option has 
been selected atSYSGEN, the contents of the fault register 
is logged in the system error file (ERRFILE,SD) along with 
pertinent context data. 

The fault condition is analyzed and a severity code 
(0 through 4) is generated according to the breakdown 
shown in Table 17. Location X' 1 AA' is interrogated for a 
machine-fault receiver pointer. If the pointer is nonzero, 
control is transferred to the receiver with the X and L reg- 
isters set as follows: 

Register X - pointer to a two-word field, where word 
contains the severity- 1 eve I code (0-4), and word 1 



contains the fault code (current fault-register con- 
tent, see Table 17). 

Register L - return location in Machine Fault Task. 

If the receiver pointer is zero, or if the receiver returns 
control (via register L), the Machine Fault Task will log 
the error and proceed, as summarized below, according to 
the assigned severity level: 

Severity Action 

Immediate exit, i.e., log fault condition 
only. 

1 Retry instruction at which fault occurred. 

2 Abort task causing the faultwith abort-code 
MF. 

3. Transfer to SYSERR routine, with code MF, 

which writes SYSERR message and brings sys- 
tem to orderly halt. 

4 Immediate system halt with code MF in 

register A, fault code in register X. 

(The receiver can change the severity level and return, with 
appropriate effect.) 

Note that, other than error logging, no action is taken on 
multiple fault conditions (severity 0), 



Table 17. Machine Fault Classification by Severity Levels 



Severity Code and Meaning 


Fault Classification 


Fault Register Contents (Hex.) 


— Error logging only. 


All faults not listed below, including any combination 
of multiple faults (i.e., faults reported concurrently). 


Any other than below. 


1 — Retryable: not second 
consecutive occurrence at 
some location. 


DIO data-in parity error. 

DFSA constantly high. 

Address-parity error on instruction fetch. 

Data-parity error on instruction fetch. 

DIO argument field error. 

DIO data-out parity error. 

NIO data parity error. 

Interrupt-Master fault. 


8210 
8204 
81 >2 
81>1 
n008 
n004 
nOOl 
0802 


2— Serious: not retryable 
but limited to a specific 
task. 


No DFSA response. 

Unimplemented instruction. 

Memory module absent (i.e., nonexistent address). 

Address-parity error on operand fetch. 

Data-parity error on operand fetch. 

PCP pseudo-fault (TRACE on and PCP interrupt). 

DIO fault: parity error on external write direct. 


8208 
8202 
81x4 
8K2 
8K1 
0804 
0801 
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Table 17. Machine Fault Classificafion by Severity Levels (cont.) 



Severity Code and Meaning 


Fault Classification 


Fault Register Contents (Hex.) 


3 — Critical: affects entire 
system . 


lOP fault. 

Watchdog timeout (special system devices). 


n020 
nOlO 


4 — Catastrophic: the 
integrity of any operation 
cannot be assured. 


All mode-3 CPU faults: 

Instruction timing error. 
ROS address-parity error. 
ROS data-parity error. 
MCM error. 
AU parity error. 

Control module error. 


83xx 
8220 


Legend: < indicates less than 8, > indicates greater than 7, n = 1 for lOPT; 2 for IOP2, and x indicates nonspecified 
value. 


The error receiver is not entered if an unimplemented instruction is executed by a background program. 

The error receiver is not entered if a nonexistent memory address is referenced by a background program (abort v/ith 
code NA). 



PROTECTION VIOUTION TASK 

Any attempt by the background to modify the contents of 
protected memory, or to execute a privileged instruction, 
will cause the Protection Violation Task to abort the back- 
ground program, using the same method as the Machine 
Fault Task. 

Unavailable core is set protected. On Sigma 2/3 systems, 
write attempts to unavailable core cause protection errors, 
and read attempts from unavailable core couse parity errors. 
The abort code after a protection error shows the location 
causing the error if the error was an invalid store or a priv- 
ileged instruction. An attempt by the background to branch 
to protected memory will cause an abort with the address of 
the location that was being branched to. Note that Mon- 
itor service routine calls actually cause a protection viola- 
tion from the background. However, if the branch address 
and the return to the background are valid, the branch is 
permitted. 

The set multiple precision mode instruction, RD X'8T, does 
not cause a protection violation when multiple precision 
hardware is implemented. 



INPUT/OUTPUT TASK 

After an input/output interrupt, the Input/Output Task 
identifies the highest priority device with a pending in- 
terrupt. It then clears the channel activity status and 
sets the operational status byte count residue in the proper 
device-file status table, if the device is no longer opera- 
ting. (The channel is not cleared for a zero-byte-count 
interrupt.) If a foreground AIO Receiver was specified (for 
a description of an AIO Receiver, see "l/O Operations" in 
Chapter 5), control is transferred to this receiver at the 
I/O priority level. It is expected that the AIO Receiver 
exits properly. 

To minimize interrupt inhibit time, the channel registers are 
loaded and the l/O initiating SIO is issued at the I/O inter- 
rupt priority level. Consequently, any task with a priority 
level higher than l/O must not use M:READ, M:WRITE, or 
M:IOEX to perform l/O, but may perform its own l/O with- 
out use of the l/O interrupt. 

When Clock 1 is employed (a SYSGEN option), M:READ/ 
M:WRITE operations are subject to a time limit. Clock 1 is 
used to ensure that no channel is active beyond a preset 
limit. If the limit is exceeded, an HIO is issued to the 
offending device and appropriate end action will be taker». 



MULTIPLY/DIVIDE EXCEPTION TASKS 

Sigma 2/3 Systems Only: These tasks simulate a Multiply 
or Divide instruction for Sigmo 2/3 computers not equipped 
with A^ltiply/Divide hardware. They are not reentrant, 
and all lower interrupts are essentially locked out for the 
duration of the simulation (approximately 250 to 300 CPU 
microseconds.) 



CONTROL PANEL TASK 

A Control Panel Interrupt causes the Control Panel Task 
to perform one of two functions: (1) remove the foreground 
task and (2) notify the RBM Control Task of o pending key-in. 
If the Control Panel data switches are set appropriately. 
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a foreground disable and abort may occur (see "Operator 
Control", Chapter 3). Otherwise, the Control Panel Task 
sets the key-in flog for the RBM Control Task, triggers the 
RBM Control Task and exits. The key-in operation itself is 
performed at the level of the RBM Control Task. 



RBM CONTROL TASK 

This task controls unsolicited key-ins and background oper- 
ations. It is the only RBM task that actually performs input/ 
output and, therefore. Is the only task that requires tempor- 
ary stack space for the reentrant RBM input/output routines. 



SCHEDULING RESIDENT FOREGROUND TASKS 

When several programs and tasks are simultaneously located 
In core memory, scheduling is required for the orderly trans- 
fer of control from one task to another. Scheduling takes 
place in accordance with the following rules: 

1. When no background or foreground task Is active In 
the system, the Monitor enters the "idle" state until 
the operator directs the loading of a set of control 
commands from an input device. 

2. After a background program is loaded, the Monitor 
transfers control to the program by an exit sequence 
from the RBM Control Task. During execution of the 
background program (if the program is waiting for its 
own I/O to complete), there can be nothing else in 
execution in the system. That is, the Monitor makes 
no attempt to multiprogram to absorb idle time. If 
there Is an armed and enabled resident foreground task 
in core, the foreground program may receive an inter- 
rupt from some external source. 



during execution by a higher priority task, up to the maxi- 
mum possible number of tasks in the system. 

Each time, a new task saves the status and register contents 
of the Interrupted task. When the new task exits, control 
is returned automatically to the task it Interrupted. If there 
is another interrupt waiting between the level of the current 
task (which is just completing) and the Interrupted task, the 
originally interrupted task is immediately interrupted again 
and the new (Intermediate) task follows the same procedure. 
Thus, it Is never necessary for any task to know what task 
precedes or follows it. The task merely preserves and re- 
stores the environment according to the established rules. 

The design of the hardware priority system makes It unneces- 
sary for the Monitor to be Involved In the actual schedul- 
ing, and this procedure allows the tasks and programs to 
independently control the execution priority of certain 
operatlonswithin the foreground. For example, a real-time 
foreground task that Is activated by an external interrupt 
may perform some processing and then Issue a special Write 
Direct to trigger another related task to continue the pro- 
cessing at a higher or lower interrupt level. If the Write 
Direct Is to a higher level, the interrupt to the higher level 
takes place immediately and the new task is begun. More 
frequently, the Write Direct is to a task at a lower priority 
level, and In this case the current task exits In a normal 
manner and the highest priority "waiting" task will become 
active. This task may or may not be the one that just re- 
ceived the Write Direct. Eventually, the task that re- 
ceived the Write Direct will be reached, and this task will 
then continue the processing at that level. Thus, real-time 
foreground programs can have an intricate scheduling scheme 
with no RBM intervention. 

An example of interrupt-d riven scheduling is Illustrated in 
Figure 5. 



3. After entry, the interrupting task saves the contents of 
any registers it will alter and proceeds to carry out its 
function. The task may use either the MrSAVE service 
routine to perform the saving opertions or it may save 
the contents of the registers itself. 

4. When the real-time task Is completed. It may restore 
the context of the interrupted task and exit via the 
standard interrupt exit procedure or may have these 
functions performed by the M:EXIT service routine. 



Warning; If the real-time task has changed the state 
of the Interrupt levels by arming or disarming 
any active interrupt, the system integrity is 
lost. The enable/disable feature should be 
used to prevent interrupts until an orderly 
exit and inactive state is achieved. 

Note that this is a last-in, first-out form of scheduling. 
The interrupting task may Itself be interrupted at any time 



LOADING FOREGROUND PROGRAMS 

All programs must reside on the RAD in order to be read Into 
memory for execution. They must be written onto the RAD 
by the Overlay Loader or the Absolute Loader. (See the 
!ABS control command description in Chapter 2 for restric- 
tions regarding the use of the Absolute Loader.) In each of 
the methods described below, only the program root is loaded 
into memory from the RAD file as a resultof the action taken. 
Segments must be read in by subsequent calls to MrSEGLD. 

The most common method of loading a foreground program 
into memory is through a call to MrLOAD by another fore- 
ground program. The call takes place at the priority level 
of the foreground program and the request is placed into the 
queue stack. The program is actually loaded by the Monitor 
subroutine S:LOAD at the level of the RBM Control Task, 
and this method is the most logical one to be used. It is 
based upon conditions automatically detected by other fore- 
ground programs and requires no response or assistance from 
the operator. 
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Note; Times need not be equally spaced. 



Time Point Activity (Meaning) 

TO The background is executing. 

Tl An interrupt is received for Foreground Task 2 which becomes active and saves the environment of the 

interrupted background task into its TCB. 

T2 Foreground Task 2 requests an I/O operation, specifies an AlO Receiver, and exits. The background 

resumes processing. 

T2.5 An interrupt is received for Foreground Task 3 which interrupts the BG. 

T3 An interrupt is received for Foreground Task 1 which becomes active and saves the environment of the 

interrupted task (Task 3) into its TCB. 

T4 At channel end, an I/O interrupt is received for the operation initiated by Foreground Task 2; the 

I/O Interrupt Task saves the environment of the interrupted task (Task 1). The AIO Receiver is 
entered at the I/O interrupt level and triggers Task 2, indicated by dotted line at FGND 2 level. 



Figure 5. Foreground Priority Levels 
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Time Point Activity (Meaning) 



15 



T6 



T7 



T8 



The AIO Receiver returns via a RCPY L, P instruction. The I/O Interrupt Task exits, restoring the 
interrupted task's status. Foreground Task 1 resumes operation, requests a checkpoint of the back- 
ground, and specifies a Checkpoint Complete Receiver. This action causes the RBM Control Task 
to be triggered, indicated by broken line at RBM Control Task level. 

Foreground Task 1 exits, restoring the interrupted task's status. This was actually Task 3, but Task 2 
is waiting and it immediately becomes active. 



Foreground Task 2 exits, restoring the interrupted task's status, 
and continues from where it was suspended. 



This was Task 3. It becomes active 



T9 



TIO 



Til 



Foreground Task 3 exits, restoring the interrupted toks's status. This was actually the background 
task. Since the RBM Control Task was triggered at 15, it is the highest waiting interrupt level. The 
RBM Control Task becomes active and stores the interrupted task's status into its TCB. The RBM 
Control Task calls the RBM subtask SrCKPT which writes the background into the RBM Checkpoint 
area on the RAD. S:CKPT then extends memory protection to the background and enters the specified 
Checkpoint Complete Receiver at the RBM Control Task level. In this illustration the Checkpoint 
Complete Receiver triggers Foreground Task 1 with a Write Direct instruction. 

Foreground Task 1 becomes active and saves the environment of the interrupted task in its TCB. The 
background area is now available to Foreground Task 1 for instructions and/or data. When processing 
is complete. Foreground Task 1 requests a restart. 

Foreground Task 1 exits, restoring the interrupted task's status (in the Checkpoint Receiver, which 
returns via a RCPY L, P instruction). The RBM subtask S:CKPT now completes its operation and 
returns to the RBM Control Task which calls in the subtask S:REST to restart the background task. 
SrREST first clears the background area, then reads the checkpointed background task in from the 
RAD. The background is then set "unprotected" which completes the restart operation. 

The RBM Control Task exits, restoring the status of the interrupted background task which then 
resumes processing. 



Figure 5. Foreground Priority Levels (cont.) 



Another method of loading a foreground program is through 
an unsolicited key-in by the operator. The operator must 
generate a Control Panel Interrupt and, in response to the 
request ! KEVIN, type in "Q name", where "name" must 
be the name of a foreground program residing in the user 
processor area of the RAD. This action also results in a 
call to MrLOAD to queue the request. This method could 
be used in response to conditions detected outside the com- 
puter system (e.g., a certain time of day). Both of the 
above methods apply to semiresident as well as nonresident 
foreground programs. For resident foreground programs, they 
would be used only to obtain a fresh copy of a particular 
program without rebooting the entire system. 

Loading through use of the queue stack requires use of the 
nonresident foreground area whether or not the request is 
for loading into this area. Therefore, whenever a nonresi- 
dent foreground program is in core, all queue stack loading 
is suspended until the program occupying the nonresident 
foreground area releases the area by unloading. 

Two other methods of loading foreground programs are avail- 
able. They involve control commands that ore normally 



used to load background programs that are part of a back- 
ground job, and that must be preceded by an FG key-in. 
These commands are 

JXEQ initiates loading from whatever RAD file to 
v/hich background operational label OV is assigned. 
The method presumes that either the appropriate 
OV opib assignment has been made, or that the 
program to be loaded is on the RAD file RBMOV 
to which the label OV is assigned by default. 

I name causes the foreground program "name" to be 
loaded in the same way a background processor is 
loaded. The foreground program must reside in 
either the SP, FP, or UP area: they will be searched 
in that order. The user is responsible for avoiding 
duplication of program names in those areas. 

The control command methods are closely tied to back- 
ground schedules and do not provide adequate response to 
real-time needs. However, they can be used when de- 
bugging foreground programs. 
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LOADING NONRESIDENT FOREGROUND PROGRAMS 

Nonresident foreground programs are also loaded by the 
Monitor service routine MrLOAD. Once loaded, these 
programs can be connected to an interrupt via an initializa- 
tion routine or else can be triggered by a code given in the 
program's TCB. These programs then behave exactly like 
resident foreground programs. If the program just loaded 
resides in the area of core referred to as the nonresident 
foreground area, the nonresident foreground area is tied up 
until the program releases this space. A method is provided 
to automatically unload this oreawhenMrABORTor MrTERM 
is colled by the task occupying the nonresident foreground 
area. Therefore, a FORTRAN program calls the library 
routine L:OP (generated by the compiler when the program 
calls STOP) to terminote and unload. If o FORTRAN pro- 
gram calls EXIT, the nonresident foreground area will rK>t 
be unloaded. 



In the case where the program contains its own TCB, the 
operand on the 'END' card will be entered at the level of 
RBM. The Initialization code in this case must 

1. Insert the PSD address into the dedicated interrupt 
location. 

2. Arm, enable and perhaps trigger the associated inter- 
rupt level. 

3. Perform any user-specified functions, such as special 
receiver connections, establishing foreground mail 
boxes, and so on. 

4. Return to the 'L' register. 

In this case, when the initialization routine executes at 
the RBM interrupt level, the RBM temp stack is available 
to the user code. This will allow enough temp for almost 
all monitor service calls. 



FOREGROUND INITIALIZATION 

When a foreground program is loaded, it may either be 
initialized by RBM (see Overlay Loader l$TCB card in 
Chapter 7) or may have its own initialization routine. 



If the l$TCB card is used, the initialization routine will be 
entered at the interrupt level specified on the !$TCB card. 
The initialization code must therefore take the necessary 
precautions to ensure that it will only be executed once. 
It must then branch to the start of the program. When 
OLOAD builds the !$TCB, the task organization is 



Org in, from 1$ ROOT Card - 

TEMP SIZE, from !$ROOT 
Card 



See Table 18 
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TEMP START 

TEMP END 

ADRL PSD 

TCB 16 



PSD 


DATA 







DATA 







STA 


TCB+ 10 




RCPY 


L,A 




STA 


TCB + 5 




RCPYI 


P,L 




B 


M:SAVE 




ADRL 


TCB 




B 


*$ + ! 


VECTOR 


DATA 


ENTRY P 


First instruction of users code 







If any module with an operand on the END card is loaded 
with the Root segment the last 'END' operand will be in- 
serted into 'VECTOR' and will be entered when the asso- 
ciated interrupt level is triggered. Otherwise, "VECTOR" 
will point ot the first word location cell of the Root. 



If HEXDUMP was included at SYSGEN time, all Monitor 
service routines except MrRSVP may be used. If HEXDUMP 
was not included, the Monitor service routines MiRSVPand 
MrSEGLD may not be used. 

For the benefit of segmented foreground programs, the ini- 
tialize code (entered by M:LOAD) can assign an internal 
operational label to the foreground ML operational label. 
This internal operational label may then subsequently be 
used in calls to MrSEGLD. The foreground program may 
not use the ML operational label in calls to MrSEGLD. 

If there is a loader built TCB, the initialization routine will 
be entered at the task level when its interrupt is triggered 
for the first time. 

When foreground initialization is completed, the routine 
returns to RBM via RCPY L, P. Foreground initialization 
routines will also be executed any time the system is booted 
from the RAD if the task is flagged as a resident foreground 
tosk and resides on the SP, UP, or FP areas. 



TASK CONTROL BLOCK FUNCTIONS 

The Task Control Block (TCB) is a convenient means for 
organizing and storing information necessary to attain pro- 
per context switching, define dynamic blocking buffer 
pools, define temporary space necessary for reentrancy, and 
arm and enable the associated task. A foreground program 
may have one or more TCBs within the program (one for each 
task), but it is assumed that the first loadable item within a 
foreground program is a TCB. The TCB is used by the AAonitor 
service routines MrSAVE, MrEXIT, MrLOAD, and by the 
Control Command Interpreter upon encountering a !C: 
command. 

The TCB consists of 17 words and can be created at assembly 
time with Extended Symbol, or at load time by the Overlay 
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Loader. (A FORTRAN program must have its TCB created 
by the Overlay Loader). The TCB is usually a block of 
code contiguous to the task it describes, with address literals 
pointing to the temporary stack space. A DATA statement 
can set the initial code for the interrupt level state for the 
task interrupt level. The complete contents of the TCB are 
shown in Table 18. 

Note: The code in TCB + 2 is the exact code used in the 
Write Direct that sets the interrupt level. This code 
is described in the appropriate computer reference 
manual . 



interrupt location and arms, enables, and optionally triggers 
the associated interrupt level. 

The background program will have a Task Control Block in 
protected foreground space. 



Caution: Locations 1 through 5 in the zero table are not 
saved and are recreated from location 6. Thus, 
locations 1 through 5 must not be changed by a 
foreground program or they will not be the same 
after interrupt has taken place. 



Bit T in word TCB+1 indicates whether the task is using the 
Monitor I/O routines and the floating accumulator; if bit T 
is zero, a temporary stack is required and the M:SAVE rou- 
time will initialize locations 0001 through 0006, after sav- 
ing the previous pointers for the interrupted task. If bit T 
is a 1 (meaning no floating accumulator and no temporary 
space are required), the M:SAVE routine will not set these 
locations. In a real-time environment it is recommended 
that a user does not set the T bit to 1 (the floating accumu- 
lator and temporary storage pointers are saved). The Moni- 
tor service routines M:SAVE and M:EXIT do not, themselves, 
use any temporary storage. 

When the task is programmed in FORTRAN, the task en- 
trance and exit, TCB, and task entrance procedure are set 
up by the Overlay Loader. The module load routine 
M:LOAD sets the pointer to the PSD into the dedicated 



When the Overlay Loader creates the TCB for a foreground 
task, the items shown in Figure 6 are generated adjacent to 
the task. If the transfer address given in the object deck is 
relocatable 0, it is not treated as the entry point to an ini- 
tialization routine, but is used as the entry address for that 
task. The task will be armed, enabled, and possibly trig- 
gered when loaded for execution depending on the contents 
of words 1 and 2 of the TCB, supplied to the Overlay Loader 
on the !$TCB card. 

After a foreground program is loaded into core, certain 
items in the TCB are examined. A fatal load error results 
if the number of specified operational labels requiring 
blocking buffers exceeds the number of available blocking 
buffers (word 15 of TCB). If the number of available block- 
ing buffers is sufficient, word 15 of the TCB is adjusted to 
reflect the current blocking buffer requirements. 





















Table 


18. 


Task Control Block (TCB) 


Location 


Contents 


Set by 


TCB+0 


ADRL PSD 


Assembler/Loader 


1 


0-3 


4 


5 


6 


7 


15 


Assembler/Loader 


R-bit No. 
For WD 


T 


C 


X 


Dedicated Interrupt Location 


2 





1 


2 


3 


4 


5 7 


8 11 


12 


15 


Assembler/Loader 


G 


D 





1 





Code 


0000 


Int. 


Group No, 


3 


ADRL TEMPBASE (temporary stack) (FWA) 


Assembler/ Loader 


4 


ADRL TEMPLIM (temporary stack) (LWA+1) 


Assembler/Loader 


5 


Contents of L register from interrupted task 


Current task (on actual entry) 


6 


Contents of T register from interrupted task 


M:SAVE (or current task) 


7 


Contents of X register from interrupted task 


MrSAVE (or current task) 


8 


Contents of B register from interrupted task 


M:SAVE (or current task) 


9 


Contents of E register from interrupted task 


M:SAVE (or current task) 
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Table 18. Task Control Block (TCB) (cent.) 



Location 


Contents 


Set by 


10 


Contents of A register from interrupted task 


Current task (on actual entry) 


n 


Contents of location 0006 (KrBASE) from interrupted task 


M.-SAVE 


12 


Contents of Location 0007 (K:TCB) from interrupted task. 


MrSAVE 


13 


Dynamic base (K:DYN) for temp of current task; 
initially TEMPBASE + 6. 


Assembler/Loader (changed by M:RES and M:POP) 


14 


Buffer pool LWA+1. 


Assemb ler/Loader 


15 


Bits 1 1-15 contain number of buffers (0 < n < 16). 
Bits 0-7 are reserved for Monitor use and should 
be coded as zeros. Bit 8 = 1 indicates the first buffer 
blocked is reserved as a sharable buffer for packed 
files. 


Assemb ler/Looder 


16 


"Use" bits for buffers in pool (0 if unused). 


M:OPENorM:CLOSE 


PSD+0 


Interrupt task status flags. 


Interrupt sequence 


1 


Interrupted task P register. 


Interrupt sequence. 


2 


First instruction of current task. 

Remainder of program (the PSD must be contiguous 
with the program but need not be contiguous with 
the TCB.) 


Assemb ler/Loader 


where 




ADRL PSD is a pointer to the Program Status Doubleword. It is the location shown in the dedicated interrupt 
location when the interrupt takes place. 


R-bif 


No. for WD is the hexadecimal value (from to F) that indicates the register bit that identifies the 
Dorticulor interrupt level within the Interrupt Group (the hardware block of 16 possible interrupts). 


T 

( 


is the flag that indicates whether the M:SAVE and M:EXIT routines should set location 0001 to 0005; 
D means yes, 1 means no. (T must be if any Monitor service routines are used.) 


C 

( 


is the flag that indicates whether the task is critical (see Glossary); 1 means yes, means no. The default 
/alue is 0. This flag is provided for interpretation and use by the installation; RBM as distributed makes no 
distinctions based upon it. 


X 


indicates whether or not the task is to be triggered ot load time: 1 means yes, means no. A code of 7 is 
ssued subsequent to issuing the code (normally 2, "Arm and Enable") given in word 2. 


D 


when set, indicates that no dismissal on wait l/O will be performed for this task. 


Code 


is the interrupt system control code that Indicates current or desired initial interrupt control status, 
rhe codes are 1 = disarm, 2 = arm and enable, 3 = arm and disable, 4 = enable, and 5 = disable, 7=trigger. 


Buffe 


r pool is an amount of space from 1 to 16 buffer areas in length, each of which is equal in size to the 
/alue contained in K:BLOCK. 


"Use 


' bits are bits, from left to right, beginning with zero, showing which of the maximum number of buffers 
lave been allocated by M:OPEN and have not yet been closed by MrCLOSE. 
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TEMP BASE 



n-word 





-»^\MnfA n 


Reserved Area 
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ADRL Word n 




1 

2 

3 

4 
5 

12 

13 
14 

15 

Word 16 




Interrupt Information 






TEMPBASE 




TEMPLIM 








K:DYN (Dynamic Temp Pointer) 




Buffer Pool LWA+1 




No. Available Buffers 


End of TCB 


Use Bits 


Word n 
ENTRY 


PSD Reserve 






STA 


TCB+10 




RCPY 


L,A 




STA 


TCB+5 




RCPYI 


P,L 




B 


MrSAVE 




ADRL 


TCB 




B 


* $ + 1 




ADRL 


ENTRY 






Foregrou 


nd Task 





= exioc, specified on 
!$ROOTcard. 

n = temp, specified on 
!$ROOT card; first five 
words of temp are float- 
ing accumulator; sixth 
word is used by FIO. 



TEMP LIM 



Supplied on !$TCB card. 



Temp Stack FWA. 
Temp Stack LWA+1. 

Reserve for saving con- 
text of interrupt task. 

Initially set to 
TEMPBASE + 6. 

Set to Common Base. 

Common Base — Last 
Loaded item/K:SEC. 

Initially set to zero. 

Two-word reserve that 
receives the interrupted 
task's PSD. 



Code to save registers, 
TCB pointers, and temp 
pointers. 



Transfer Address 



Figure 6. Task Entrance Format 
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In the event of a fatal load error in response to a load 
request from a background job stack via an !XEQ or Incme 
command, the following message is printed on the DO: 



! !BKGD XE ABORT LOCATION FFFF 



If the request came from a queue stack load, the following 
message is logged on the DO: 



NONRES FOND PGM xxxxxxxx LOAD ERROR 



If a program has an initialization routine (that is, an end 
transfer address other than absolute or relocatable 0), that 
routine is responsible for storing word of the TCB (the ad- 
dress to receive the interrupted task's PSD) into the dedi- 
cated interrupt location, as well as arming and enabling the 
appropriate interrupt level for each task within the program. 

The initialization routine may also be used to assign any 
specific operational labels required by the program (e.g., 
the operational label or device unit number required) to 
read in subsequent segments. 

If the program has no initialization routine, word of the 
first loaded task (actually word of that task's TCB) will 
be stored into the dedicated interrupt location for that task 
when the program is loaded. Next, the associated inter- 
rupt level is disarmed to remove any waiting interrupts; then 
it is armed, enabled, and possibly triggered, depending on 
the contents of words 1 and 2 of the TCB. 



FOREGROUND PRIORITY LEVELS AND I/O PRIORITY 

All foreground tasks that have a priority level lower than the 
I/O priority level and that operate without interrupts inhib- 
ited may use the Monitor l/O routines without any special 
restrictions. However, foreground tasks that have interrupts 
inhibited or have an interrupt level higher than the I/O pri- 
ority level must not use Monitor I/O. 

The recommended procedure for a task whose interrupt level 
is higher than the I/O priority level is to trigger a task 
whose priority is lower than the l/O priority. This lower 
priority task would then perform the required I/O operations. 
Generally, these high-level tasks are for emergency situa- 
tions where no I/O is performed or when the task does its 
own I/O due to special requirements. 



TASK DISMISSAL 

When the SYSGEN option DISMISS is selected, the resident 
M:READ/M:WRITE code is extended so that any foreground 
task that elects to wait for on-going I/O to complete will 
be automatically suspended, allowing lower priority tasks 
(e.g., background) to proceed. This is accomplished by 
constructing an AIO receiver for the suspended task, which 
will reawaken the task when I/O completes. The implicit 
consequences of the scheme are: 



When a foreground task is activated, control is transferred 
to the address given in the dedicated interrupt location, 
where the interrupted task's PSD is stored, and execution 
resumes at PSD + 2 at the level of that foreground program. 
This is a hardware function that preserves the interrupt status 
and execution location of the interrupted task. Next the 
register contents of the interrupted task must be saved. 

Normally, the first instruction in a foreground program 
will store the contents of the accumulator into word 10 and 
the contents of the L register into word 5 of its TCB and then 
go to the Monitor service routine MiSAVE which will store 
the remaining register's contents into the active task's TCB. 
M:SAVE will also store the contents of KrTCB (used exten- 
sively by the Monitor to identify the currently active task) 
into word 12 of the TCB, and set KrTCB to point to the 
active task's TCB. If the active task requires temporary 
storage (word 1, T = 0), the contents of K:BASE are stored 
into word 1 1 of the TCB and K:BASE is set to the first word 
address of the active task's temp stack. The floating ac- 
cumulator is then set to point to the first six cells of the 
active task's temporary storage. 

When the currently active task has completed all its opera- 
tions, it exits through the Monitor service routine M:EXIT 
which restores the general register's contents and resets 
KrTCB and, if applicable, KrBASE. MrEXIT also performs 
a hardware exit sequence, by which it restores the interrupt 
status and the overflow and carry indicators, and returns to 
the interrupt task. 



If the task must forestall lower priority processing, it 
must be flagged for "no-dismissal" if I/O is performed 
(see description of TCB "D" bit, above). The RBM con- 
trol task is flagged in this fashion. 



2, Dismissal is transparent to the task; however, there 
is no overlapping of a task's I/O with computation 
while the task is dismissed. Overlapping of compu- 
tation and I/O within a task can only be accomplished 
with "no-wait" M:READ/WRITE (and other) service 
calls; regardless of whether or not "DISMISS" is 
included. 



3. Dismissal can occur on "no-wait" I/O but only when 
the requested device is already busy; in which case, 
the task will be suspended until the device becomes 
free and return will be made after the I/O is initiated. 
Double buffering can be achieved by a "no-wait" Read, 
followed by a "WAIT" write from a different buffer, 
followed by a "WAIT" check on the original read and 
then repeating the process. Such a task will proceed 
at the rate of the slower device. 



4. By continually accessing only one device, a task may 
prevent lower priority tasks from accessing that device. 
Therefore, a foreground task that accesses the system 
RAD excessively may effectively suspend background. 
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AlO RECEIVERS 

An AIO Receiver is a means whereby a foreground program 
can initiate an I/O operation, release control to lower 
level tasks, and regain control when the l/O operation is 
completed. The AIO Receiver itself is a closed subroutine 
which operates at channel end (or zero byte count, if 
specified) at the priority level of the I/O interrupt. It is 
used in conjunction with an l/O operation specifying 
"initiate only and return" (no wait). Typically, in order 
to maximize compute and I/O overlay, the foreground pro- 
gram will issue an I/O request with the "no wait" option 
and specify an AIO Receiver. When the l/O operation is 
successfully initiated, this foreground task exits from the 
active state (by a call to M:EXIT) and is restored to the 
active status at channel end by a Write Direct to trigger 
the interrupt level (from its AIO Receiver). The next I/O 
operation for that device file-number must be a "check" 
operation to complete the end-action of the file. 

For I/O to RAD files, the AIO Receiver may be activated 
before the operation is actually complete. This will happen 
whenever a transfer across a disk track boundary occurs, 
more than X'IFFF' bytes are requested, or a flawed track 
Is encountered. The calling task (not the AIO Receiver) 
must issue a "check" operation to complete the transfer. 
An AIO Receiver specified for the "check" operation will 
be honored. 

Special considerations for use of AIO Receivers are: 

1 . The operation requesting an AIO Receiver is an 
"initiate and return" operation. If the device or the 
file is busy, the I/O operation is not initiated and a 
busy status is returned. It is the user's responsibility 
to determine the course of action to be taken at this 
point (e.g., loop until ready or ignore the operation). 

2. If the file being used is a blocked file, an actual I/O 
operation may not be required, hence no channel end 
interrupt and no AIO Receiver operation. In this in- 
stance, the X register will be set to -1 to Inform the 
user that the AIO Receiver will not be effective. A 
"check" operation is still required on the file before 
another I/O operation may be performed. 

3. If a "check, no wait" is performed on a device that is 
busy with some file other than that specified by the 
check call, the check operation will be performed 
with an implied wait but only until the device is free 
for use by the specified file. For example, a busy 
status returned on a "check, no wait" operation always 
applies to the file specified by the Check call and if 
an AIO Receiver was specified, it will be honored. 

4. If the AIO Receiver merely retriggers the task that ini- 
tiated the operation, a danger exists in that it is quite 
possible for the AIO Receiver to operate before the 
task exits from its "active" state. Thus, the currently 
active task is retriggered, which results essentially in 
a no-operation. One means of avoiding this problem 
would be to have the AIO Receiver set a flag to Inform 
the active task that it has run. In this way, the active 



task could inhibit interrupts prior to exiting, test 
whether the AIO Receiver has already operated, and 
if so, restore interrupt status and return to the start of 
the task. If examination reveals that the AIO Receiver 
has not run, the task merely exits through MrEXIT which 
will properly restore the interrupt status. Another 
means of avoiding this difficulty is to have the AIO 
Receiver trigger a task lower in priority than the active 
task. This lower priority task could retrigger the task 
initiating the I/O operation, thereby providing a posi- 
tive trigger. 

The form of the call to the AIO Receiver by the I/O Inter- 
rupt task Is 



LDA 



RCPYI 



B 



aiodsb 



P,L 



(device status byte 
from AIO In bits 0-7, 
device number in 
bits 8-12) 



AIO Receiver Address 



The AIO Receiver routine must return to the location con- 
tained in the L register on entry. All registers are assumed 
to be volatile, which means that they need not be saved 
and restored to their former contents. Because the AIO Re- 
ceiver is processed at the priority level of the l/O Interrupt 
the processing in this routine should be of very short dura- 
tion so as not to interfere with other l/O operations that 
may be In process. See also "End Action" in Chapter 5. 



CL0CK1 RECEIVER 

Extended zero table location X'IB4' contains a pointer to 
the CLOCKl receiver chain. The S24RBM procedure file 
equates symbolic reference CLKIRXR to this location. 

The receiver is entered at the counter 1 = level. At entry, 
the A register will contain the actual counter 1 =0 reentrancy 
count so that if it is desired to avoid repetitive operations 
where the counter 1 = pulses have effectively stacked up, 
the receiver need only test for a change in the contents of 
the A register. All registers except A are considered vola- 
tile. The SYSGEN specification CLKlFREQ,n specifies the 
desired frequency (see SM Reference Manual 90 30 36) 
which defaults to l/lO second but may be set to a value 
from l/lOO second to one second. 

All receivers connect by first saving the current contents of 
the receive location CLKIRXR at their entry address -1 and 
then storing their entry address at CLKIRXR. 

The delinking process requiresa searchof the receiver chain 
for the position within the chain of the delinking task and a 
substitution of the delinking's task exitaddress for that posi- 
tion within the chain. 

Note that interrupts should be inhibited whenever the chain 
is manipulated. The following code might be utilized to 
connect and to delink from the chain. 
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To connect: 




INHIBIT 


R:PSW1 


LDA 


CLK1RXR 


STA 


MYENTRY-1 


LDA 


=MYENTRY 


STA 


CLKIRXR 


RESTORE 


R:PSW1 



Assuming tasks A, B, and C had connected in that order to 
the CLOCK! receiver, the CLOCKl receiver chain would 
be as follows: 



CLKIRXR 



TASK C EXIT 



TASK C ENTRY 





TASK B EXIT 


TASK B ENTRY 








TASK A EXIT 


TASK A ENTRY 



'Original value of 
CLKIRXR 



To disconnect: 








INHIBIT 


R:PSW1 




LDX 


=CLK1RXR 


SEARCH 


LDA 


0,1 




CP 


=MYENTRY 




BNC 


$+2 




B 


ITSME 




RCPY 


A, X 




RADD 


*Z,X 




B 


SEARCH 


ITSME 


LDA 


MYENTRY-1 




STA 


0,1 




RESTORE 


R:PSW1 



CHECKPOINTING THE BACKGROUND 

A foreground program may require use of the background 
area for either instructions or data. A checkpoint feature 
is included in RBM to allow access to the background area 
by a foreground program by writing any active background 
program onto the RAD and extending memory protection to 
the background area. 

A checkpoint operation is initiated by a call to MiCKREST 
with the appropriate option. M:CKREST will return a status 
specifying whether or not the request Was honored. The 
request will not be honored if the background has already 
been either checkpointed by a foreground request or auto- 
matically checkpointed as a result of loading a nonresident 
foreground program extending into the background. It is 
the responsibility of the user to schedule the use of the 
background space by foreground programs. The actual 
checkpointing is accomplished either at the priority level 
of the RBM Control Task or at the priority of the Calling 
task. 



If the checkpoint is performed at the priority level of the 
calling task, a return from M:CKREST with a status of zero 
(A = 0) indicates that the checkpoint has been performed. 
If the checkpoint is to be performed at the level of the RBM 
Control Task, the requesting program must exit its "active" 
state to allow the checkpoint operation to be performed. 
The program requesting the checkpoint would generally 
specify a "Checkpoint Complete Receiver". This receiver 
is operated at the priority level of the RBM Control Task 
when the checkpoint is complete. 

The receiver will generally retrigger the requesting pro- 
gram to inform it of the completion of the checkpoint. 
Return from the Checkpoint Complete Receiver is to the 
location contained in the L registers on entry. All registers 
are assumed to be volatile, and need not be saved and re- 
stored to their former contents. 

When the foreground program no longer requires use of the 
background area, it should restart the background task by 
a call to M:CKREST with the "restart" option. 
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7. OVERLAY LOADERS 



Two loaders, OLOAD and BLOAD, are provided with RBM. 
Functionally, they are quite similar. The two major dif- 
ferences are (1) Public Library loading is supported only by 
OLOAD, and (2) BLOAD creates a load module one granule 
at a time. Thus, OLOAD runs faster than BLOAD, but 
BLOAD can load program segments larger than the available 
loading space. In this chapter, statements or paragraphs 
applicable only to OLOAD or to BLOAD are indicated 
parenthetically. 

The Overlay Loaders can be used to create overlay program 
load modules for later execution in either the foreground or 
background. Overlaid programs can be permanently entered 
(as a file) into either the system or user processor areas, or 
into a temporary overlay file. Since they are stored on the 
RAD as an absolute core image, they can be quickly loaded 
Into memory for execution. 

A general overlay structure is illustrated in Figure 7. The 
structure is restricted to a permanently resident root seg- 
ment and up to 255 overlay segments. (For background 
and nonresident foreground programs, the permanent root 
segment is resident only during actual execution. ) For fore- 
ground programs, the TCB and the initialization routine 
(if one is present) must be in the root segment, but data 
and instructions can be located in both the root and the 
overlay segments. 



In creating core images on the RAD, the Overlay Loaders 
perform the following functions according to user options: 

« Satisfy external reference/definition linkages and re- 
solve forward reference and displacement chains. 

• Search specified libraries for unresolved references and 
load these selected routines into core memory. 

• Build the OV:LOAD table for the loading of overlay 
segments. 

• Write the overlay cluster onto the OV file. 

• Allocate COMMON. 

• Allocate temporary storage stacks. 

• Create a Task Control Block (TCB) and initialization 
information. 

• Create the Public Library and associated transfer vectors 
(TVECT)(OLOAD only). 

• Output maps of segment names and addresses, external 
definitions, and information concerning COMMON and 
temporary areas to the LO device. 

• Allocate, initialize, and satisfy reference linkage for 
Labeled COMMON. 



A Blank COMMON data area can also be established 
for use by the root and overlay segments. 

Each segment is created by the Overlay Loaders from one 
or more object modules (assembly language, FORTRAN, 
or RPG output). The control commands required to create 
the overlay segments are defined in this chapter. During 
execution, the Monitor service routine MrSEGLD is used to 
control both the loading and the transfer of control between 
various segments. 

The overlay segments must be explicitly defined at load 
time and explicitly called at execution time. There is no 
provision for automatically calling in a new overlay seg- 
ment by a subroutine reference. However, the subroutines 
on a particular path may communicate with each other, with 
the restriction that it is the program's explicit responsibility 
to ensure that any subroutine referenced is currently in 
core. 



OVERLAY CLUSTER ORGANIZATION 

The overlay cluster is the collection of absolute overlays 
formed by the Overlay Loaders from relocatable binary ob- 
ject modules. (Note that the Loaders do not accept an 
absolute load origin in any input module. ) An overlay 
cluster usually consists of two principal sections: the root 
segment and the overlay segments although It may consist 
of only a root segment. Each segment consists of one or 
more binary modules and associated library routines. Over- 
lay segments are numbered in any order by the user, except 
for the root segment, which is always designated as seg- 
ment 0. Those segments In core memory at any one time 
form a path. An overlay cluster with several paths is shown 
In Figure 8. Segments are shown as horizontal lines and, 
in this example, are numbered In the order In which they 
are built by the Overlay Loaders. Note that a given node, 
each path associated with a branch must be completed before 
a new branch is connected to this node. 



The Overlay Loaders accept input in Xerox Standard Object 
Language from predefined, preposltioned files, and prepare 
output in absolute core-image form on the RAD to be read 
by the RBM Loader (MrLOAD) for later execution in either 
foreground or background areas. If a resident or nonresident 
program can tolerate a loading delay of 20 to 100 milli- 
seconds, foreground or background programs of virtually 
unlimited size can be constructed by the use of overlays de- 
spite limitations in available core storage. 



The overlay cluster shown in Figure 8 consists of a root and 
segments 1 through 15. Segments 0, 1, 3, 4, 5, 6 constitute 
a path. On the RAD or disk pack the root is preceded by 
a file header, one RAD granule In length, that contains In- 
formation by which the RBM Loader MrLOAD can correctly 
read the root. The root is resident at all times during exe- 
cution of the overlay program and contains information 
(OVrLOAD table) for loading of the remaining overlay 
segments. 
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No. 0) 



I Root Area I 



Low Core 



Overlay Segment n 



Overlay Segment No. 3 



Overlay Segment No. 2 
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No. 21 



Overlay Segment 
No. 22 



Overlay Segment No. 1 



Overlay Area 
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COMMON 
Data 
Area 



COMMON 

Area 

(Optional) 



High Core 



Figure 7. General Overlay Structure Example 
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Figure 8. Sample Overlay Cluster Configuration 



When first defined along a path by an object module, 
Labeled COMMON will be allocated preceding that mod- 
ule. Should the same Labeled COMMON be subsequently 
defined by another module, the area prescribed should be 
no greater than that already allocated, and reference to 
the initial definition will be provided. Allocated space for 
Labeled COMMON is cleared to zero entries except where 
data is provided by modules of the same segment (or root). 
An XSYMBOL subroutine may access Labeled COMMON 
via an external reference (REF or SREF) if the Labeled 
COMMON is defined in a previously loaded module. 

Library modules of the root may not initialize Labeled 
COMMON allocated in the program portion of the root. 
The number of Labeled COMMON blocks associated with 
a module is limited to 40. 

Communication between segments by external reference/ 
definition linkages is subject to the following restrictions: 

1. No segment in a path may reference a segment in an- 
other path. 

2. The user must ensure that all communicating segments 
are in core memory during execution. 

3. Because the Overlay Loaders will satisfy a linkage only 
within a path, identical references and definitions 
may be used in different paths that do not contain a 
common segment. However, the user must avoid refer- 
ences to the same definition in different higher level 
segments. 

4. Library search procedures for a User or System Library 
restrict the use of unique library DEFs and REFs to a 
maximum of 300 along any path of the program. 

5. Forward references in library modules of the root are 
disallowed, and it is suggested for good programming 
practice that User Library programs not make references 
outside the library realm. 



To satisfy any remaining unsatisfied primary references, the 
Overlay Loaders search the following libraries In the spec- 
ified sequence: 

1. Public Library 

2. Monitor Service Routines 

3. Basic or Extended Library (optionally) 

4. Main Library 

CORE LAYOUT DURING LOADING 

Background memory during the operation of the Loader is 
divided into four areas: 

1. A fixed area large enough to contain the background 
temp stack, the Loader root, and the Loader overlays. 

2. The segment table, fixed at 10(n + l) where n equals the 
number of segments. 

3. In OLOAD, a dynamic area in which the segment Is 
loaded. In BLOAD, a fixed (granule sized) length block 
for segment loading. 

4. A dynamic area containing the symbol tables (allocation 
Is five to eight words per symbol). 

If areas 3 and 4 overlap at any point in the load process, 
overflow occurs and loading aborts. 



OVERLAY LOADER OPERATIONAL LABELS 

The Overlay Loaders reference the operational labels listed 
below. Some assignments are user-defined, while others 
are handled internally by the Job Control Processor or by 
the Loader Itself. All other operational labels referred to an 
I $LD cards must be assigned and positioned by the user prior 
to the ! OLOAD or I BLOAD command. 

Label Explanation 

CC Control commands. If a KP key-in is in effect, 

control commands are read from OC. 

DO Diagnostic messages. The default assignment is 

that given by the Job Control Processor on read- 
ing a jJOB card. 

GO Sequential-access file that contains object mod- 

ules to be processed by the Overlay Loaders. 
Object modules are written onto GO by a pre- 
ceding processor. The Loaders rewind GO ini- 
tially, and also after loading is completed. GO 
receives a default assignment by the Job Control 
Processor to the permanent file RBMGO in the 
System Data area. 
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Label Explanation 



Label Explanation 



LO Mops. 

LI Assigned tntemqUy for file I/O. 

LL Log of control commands. 

OC Abort messages ond Overlay Loader nriessages that 

require operator attention. Control commands 
are read from OC if a KP key-in is in effect. 

OV Output file (random format) for the Overlay 

Loaders containing the completedoverlay cluster. 
If the user wishes to have the overlay cluster in 
a permanent file, he must key in SY (for write- 
protected files) and assign OV to that permanent 
file. By default, OV is assigned to the permanent 
file RBMOV in the System Data areo. 

PI Used for loading the Overlay Loaders' own over- 

lays. PI is assigned by the Job Control Processor. 

XI Temporary RADor disk pack scratch file contoin- 

ing the symbol table for eoch segment. XI is 
assigned by the Job Control Processor. 

ID An optional operational label used to write the 

idents of non library programs for use by Debug at 



ID execution time. If the user assigns ID, the 

(cont. ) assignment must be for a packed file that has a 
record length of five words. By default, ID is 
assigned by the Job Control Processor to RBMID 
(a one-sector file) in the System Data area. 



MAP 

Three types of maps may be output to the LO device fol- 
lowing PASS2, according to one of three Map control 
commonds that may be input: a Short Map (!$MS), Long 
Map (!$ML), or Program Map (f$MP). If no Map control 
command is specified, no map will be output. 

Figure 9 shows the formot for a Long Map. NJote that 
DEFs in the Permonent Symbol Table are mapped offer 
the Overlay Task line. The format for a Program Map 
would be the same as the Long Map except that library 
and Permanent Symbol Table symbols are suppressed. The 
lines of the mop that are flagged with on asterisk (*) show 
the format and output of a Short Mop (in on actual Short 
Map no asterisk would appear in the listing). A definition 
of each item of the map is included in Figure 9. 



'•^MAP 








fFO 
^'OVERLAY TASK ORG = xxxx 
IBAJ 


HLLOC = xxxx CBASE = xxxx 


CSIZE = xxxx UMEM = 


xxxx SECT = xxxx 


"ROOT ORG = xxxx LWA = xxxx 


fNONE 
LEN = xxxx TRA = 

xxxx. 


SEV = xxxx OV:L()AD 


= xxxx 


f 1 




s 


B 








rf "1 DEF symbol 




u 


E 


yyyy DEF symbol . . 


.etc , 






-P 


M 








1 




S 


B 








[f^f^jREF symbol I 


[| 


U 
P 


E 
.M 


zzzz REF symbol . . 


.etc . 




^SEGMENT IDENT NODE 


ORG LWA LFN TRA 


SEV 




xxxx xxxx 


xxxx xxxx xxxx xxxx 


xxxx 




rf ] DEF etc. 








[f^fjREF etc. 








REF 








^-SEGMENT 








^SEGMENT 








*ERRSEV = xxxx 








*END MAP 






. 



Figure 9. Long (Load) Map Format 
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where header keywords have the following meaning: 


Overlay Task Keyworc 


s 


ORG 


First word address of the Overlay Task area. It is the FWA of the Temp stack. 


HLLOC 


Last word address of longest segment. 


CBASE 


Base of Blank COMMON. 


CSIZE 


Largest Blank COMMON size encountered. 


UMEM 


The number of locations between the end of the longest path, and either the beginning 




of Blank COMMON or the end of the assigned task area. 


SECT 


The number of sectors required to store entire overlay cluster. 


Root Keywords 




ORG 


FWA address of the root. In the foreground, this is assumed to be the address 




of the TCB; in the background, it is the FWA of the root. 


LWA 


Last word address of the root segment. The area from ORG to LWA includes 




the root code and the OVrLOAD table (and in the foreground, the TCB). 


LEN 


LWA-ORG+1. 


TRA 


Background — last end transfer encountered on a module used to form the root. If there 




is no transfer address, 'NONE' is output. 




Foreground — the entry address of an initialization routine that arms and optionally 




triggers interrupts at run time. If the Loader builds the TCB, it is assumed that no 




such initialization exists and TRA=NONE. 


SEV 


Error severity encountered during loading binary modules. Taken from the END item of 




the binary module - 


OV.-LOAD 


Address of the OVrLOAD table. 


General Keywords 




^^2 


Error and identifier flags preceding external definitions and references. Possible flags 


are: 




D Double definition or reference. 




LC Labeled COMMON 




U (DEF) — a definition declared, but given no value. 




U (REF) — reference unsatisfied in this path. 




P Primary reference. 




S Secondary reference. 


DEF 


An external definition. 


REF 


An external primary or secondary reference. 


symbol 


DEF/REF name of one to eight EBCDIC characters. 



Figure 9. Long (Load) Map Format (cont. ) 
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General Keywo 


rds 


(cont.) 


L/I 




Library or Input REF/DEF. 


S/U/P 




System, User, or Public Library. 


B/E/M 




Basic, Extended, or Main mode. 


yyyy 




ValueofaDEF. 


zzzz 




The number of the segment in which this reference was satisifed. For unsatisfied 
references, zzzz is blank. 


Segment Keywo 


rds 




IDENT 




Numerical identifier of this segment as found as the first parameter on the !$SEG card. 


NODE 




The numerical identifier of the segment to which this one will be attached. If NODE 
is the root, is output. 


ORG 




Beginning location (execution) of this segment. The point in core at which loading 
begins. The first reserves before data in a segment are not output. 


LWA 




LWA of this segment. Includes areas defined by RES and ORG. 


LEN 




LWA-ORG+1. 


TRA 




The last encountered transfer address is placed as an entry point in the OV.-LOAD table 
for this segment. 


SEV 




Same as for ROOT. 


ERRSEV 




Total error severity for loading process. If any SEV > or there are unsatisfied primary 
references, ERRSEV=1. Only in forming a PUBLIBdo double DEFs or unsatisfied secondary 
references cause ERRSEV=1. Errors in the input binary may cause ERRSEV=2. 


END MAP 




Completion of loading process. 



Figure 9. Long (Load) Map Format (cont. ) 



Certain reserved DEFs will be output by the Loaders. These 
are: 

P:FWA Program First Word Address 

P:LWA Program Last Word Address 

P:TCB Primary TCB FWA (if the Loader builds the TCB, 

otherwise, not generated) 

P:RLWA Root Last Word Address is an overlaid program 

(suppressed for root-only programs) 

These are treated as external definitions and may be refer- 
enced by the program. 

P:LWA and P:RLWAare restricted todefinition by the Loader. 
User definition of these syrribols will result in indeterminate 
results. They may, of course be referenced by user code. 

P:FWA and P:TCB may be user defined, but they will be 
flagged as duplicates and otherwise ignored. 



CALLING OVERUY LOADER 

The Overlay Loaders are requested via an lOLOAD or 
IBLOAD command which causes the root segment of the 
Loader to be read into core memory from the RAD. The form 
of the command is 

/ 

lOLOAD [segments, ,S,D,X,cmn][,R] 

or 

! BLOAD [segments, IgK S, D, X, cmn][, R] 



wher 



segments denotes the number of segments in the 
overlay cluster. If "segments" is not specified, 
a zero is used, denoting that only a root segment 
is to be loaded. The value of the segments param- 
eter may exceed the actual number of segments to 
be loaded. 



92 Calling Overlay Loader 



F or B specifies either a foreground (F) task or a 

background (B) task. The default case is 
background. 

S specifies a step mode of loading to be used for 

paper tape input. 

D indicates the ident of each non library module is 

to be written to operational label ID for use by 
Debug at execution time. 

X indicates that the Loader is to abort the job if a 

severity error greater than zero Is encountered dur- 
ing loading. The loading procedure is completed 
and the map is output. 

cmn for background tasks, cmn denotes an optional 

Blank COMMON size. For foreground tasks, cmn 
denotes a base for Blank COMMON. A check is 
made at the end of the load to determine whether 
the Blank COMMON allotment overlaps the root. 
If it does, the warning message $$ ERR CO is 
printed but no error severity level is set. 

R for foreground tasks only, specifying this param- 

eter causes only the root size to be entered into a 
sector header (OVrLOAD table) instead of the pro- 
gram's longest path. 

This action is intended for the use of a foreground 
program that only occasionally uses a large data 
buffer. A program of this nature can reside in 
foreground without checkpointing background until 
such time as it requires background space. Caution 
must be exercised in the use of this parameter, 
since the background must be explicitly check- 
pointed and restored, when necessary, by the fore- 
ground task. 

When the step mode of loading is defined, the operator is 
notified after the loading of each module from paper tape 
by the message 



! [BEGIN WAIT 



Depressing the console interrupt button and keying in an S 
will initiate either the loading of the next module from the 
paper tape unit or the reading of the next control com- 
mand. An X response causes the loading process to abort. 

In allocating COMMON for background programs, the 
Overlay Loader compares the cmn parameter with the first 
nonzero COMMON size allocation value encountered in 
loading and employs the larger of these two values. The 
COMMON base is set by subtracting the COMMON size 
from K:UNAVBG. 



Reading an jEOD control command causes the Overlay 
Loader to satisfy forward references, output any specified 
map, close files, and return control to RBM via M;TERM. 
The form of the command is 

!EOD 



CONTROL COMMAND FORMAT 

Except for the lOLOAD and IBLOAD commands which are 
read by the Job Control Processor, the Overlay Loader 
control commands are read from the CC device under Loader 
control, unless a KP key-in is in effect, in which case con- 
trol commands are read from the OC device. The general 
format of control commands is 

!$mnemonic parameter 



! identifies the record as a control command. 

$ indicates that the control command is unique to 

the Overlay Loader. 

mnemonic is the code name of an Overlay Loader 

control command and begins immediately following 
the j$ characters. 

parameter is a series of optional or required param- 

eters unique to the specific command.' The formats 
of parameters are (1) a decimal integer of up to 
five positive numbers but having a value less than 
32,767; (2) a hexadecimal string of the form 
ixxxx; (3) an EBCDIC string of up to eight char- 
acters but not exclusively characters through 9; 
or (4) a string of the form EBCDIC string ± hexa- 
decimal number. 



From one through eight blanks are permitted between the 
mnemonic and the first parameter. If more than eight 
blanks are detected, the parameter list is considered empty. 

The only allowed delimiter between parameter fields is a 
comma; no embedded blanks are allowed in or between any 
fields. A single blank terminates the parameter string. 
Two successive commas indicate an empty field. Com- 
ments are allowed on a control card. 



BLANK COMMON ALLOCATION IN FOREGROUND LOADING 

For foreground loads, the Overlay Loader allocates Blank 
COMMON and blocking buffer pools in accordance with 
the rules delineated in Table 19. 



CONTROL COMMAND REPERTOIRE 

BLOCK The !$BLOCK control command will allocate 

blocking buffers from unused memory space as requested 
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Table 19. Foreground Load Blank COMMON Allocation 



Program Type 


cmn Specification 


CBASE 


Program Limit 


BB Pool End 


Resident Foreground 


< Program origin 
> Program origin 
Not specified 


cmn 
cmn 
FGLWA-CSIZE 


FGLWA 

cmn 

CBASE 


!$BUFEND (required) 
!$BUFEND (required) 
!$BUFEND (defaults to CBASE) 


Nonresident 
Foreground 


< Program origin 
> Program origin 
Not specified 


cmn 
cmn 
FGLWA-CSIZE 


BGLWA 

cmn 

CBASE 


!$BUFEND (required) 
!$BUFEND (required) 
!$BUFEND (defaults to CBASE) 


Nonresident 
Foreground with 
R Option 


< Program origin 
> Program origin 
Not specified 


cmn 
cmn 
BGLWA* 


BGLWA** 

cmn 

CBASE 


!$BUFEND (required) 
!$BUFEND (required) 
!$BUFEND (required) 


where 

CBASE is the first word address of COMMON. 

CSIZE is the size of the first COMMON declaration encountered. 

FGLWA is the last word address of foreground (K:BACKP-1). 

BB POOL END is the blocking buffer pool last word address plus 1. 

BGLWA is the last word address of background. 

cmn is the COMMON specification parameter on the lOLOAD command. 


^f Blank COMMON is encountered in the root, a warning is Issued ($$ ERR CI), CBASE is set to FGLWA-CSIZE and the 
R option is ignored. 

If the root exceeds FGLWA, a warning is issued and automatic checkpoint will occur at program core-load time. 



either by a count or by defining operational labels that 
may require blocking buffers at run time. The list of such 
labels along with limits of available memory will be passed 
via the file header to MrLOAD, which will allocate a 
blocking buffer pool at run time. The pool will be uti- 
lized dynamically to provide blocking buffers in cases 
where a call to RBM routines M:READ or M:WRITE is not 
preceded by a call to M:OPEN. A call to M:CLOSE may 
release any such buffers. Thus, if two operational labels 
were to use a blocking buffer area at different times, the 
first might release the area for use by the second. Only 
one of the two labels would be required on the !$BLOCK 
command. 



Only one !$BLOCK command is allowed in a single job 
step, except when used with multiple !$TCB commands. 
The format of the !$BLOCK command is 



!$BLOCK 



op lb] [,oplb2/ 
ALL 



,oplb^] 



Ds] 



where 



MrLOAD checks which of the operational labels are as- 
signed to block files at run time to make the pool alloca- 
tion. If such an allocation overflows the available memory 
space (between the end of the longest path and COMMON), 
the execution aborts. However, the user may define his 
own blocking buffer by specific calls to MrOPEN. Such 
an area should be in a reserved area of his own path. He 
should not use the dynamically allocated pool area, and 
blocking buffers may not be allocated in temporary stacks. 



oplb| defines an operational label (which is a two- 

letter mnemonic or a FORTRAN device unit num- 
ber; e.g., BI, SI, F:106. The oplb| parameter may 
not be a device-file number or file name. The 
opib must be assigned to a blocked file. Only 10 
operational labels will be read; additional ones will 
be ignored. In lieu of operational labels, the user 
may provide a count (c)of blocking buffers required. 
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ALL results in the entire area of unused memory 

(UMEN) being used as blocking buffers to a maxi- 
mum of 16. 



it occurs. If the !$LIB command is not present, OLOAD 
follows the default case (Basic System Library search). The 
format of the command is 



defines a count of buffers required to a maximum 
of 16. 

indicates that the first of the indicated buffers is 
to be set aside as sharable by packed random files 
(see "Blocking Buffers", Chapter 5). 



!$LIB[m,x[,y]][,NP] 



wh€ 



BUFEND The l$BUFEND command must be used to 

specify the LWA+1 of the blocking buffer pool for fore- 
ground loads if required by the rules specified in Table 19. 
Only one l$BUFEND command applies during a load se- 
quence. Buffer requirements must be specified by an 
!$BLOCK command. The lack of buffer specification, or 
overlap with COMMON, program, Publ ic Library, or Monitor 
areas will cause an Overlay Loader error message ($$ERR BU). 
The format of the command is 



1$BUFEND 



where 



loc 
CB 
PP 
BL 
NL 
RL 
IPF 



loc is a decimal or hexadecimal address. 

CB indicates that pool LWA+1 = CBASE. 

PP indicates that pool LWA+1 = program LWA plus 

pool size. 

BL indicates that pool LWA+1 = BGLWA. 



NL indicates that pool LWA+1 = nonresident 

FG LWA. 



RL indicates that pool LWA+1 = resident FG LWA. 



m specifies the search mode and is one of the fol- 

lowing EBCDIC codes: 

Code Search Mode 

B Basic (and Main) 

E Extended (and Main) 

M Main only 

xr,yj specify the order of search, and are either of 

the following EBCDIC codes: 

Code Library 



System 
User 



NP 



The order in which x and y are specified deter- 
mines the order of library search. If only x is 
specified, y will not be searched. 

specifies suppression of Public Library linkage 
if the !$LIB command precedes a !$ ROOT com- 
mand. If the NP parameter occurs on a LIB com- 
mand following a !$ROOT command, or in a 
PUBLIB load, NP is ignored; any other param- 
eters in the command are interpreted as described, 
however. 



An !$LIB command with no parameters or with only the 
NP parameter will suppress nonresident library search from 
the point of its occurrence in the OLOAD control com- 
mand stream. 



MS,ML,MP The Map control commands specify that 

map information is to be output on LO. The three forms 
of map commands are shown below. 



PF indicates that pool LWA+1 = program FWA. 



See also "COMMON Allocation for Foreground loading. 



LIB The !$LIB control command specifies the library 

search sequence for the entire load process, or from that 
point in the OLOAD control command sequence at which 



If the ! $MS (Short Map) control command is specified, only 
root and segment headers will be output. Also output is a 
summary containing the origin of the overlay program, the 
length of the longest path, temp stack size, memory that is 
avoilable for the blocking buffer pool, and the COMMON 
base. The format of the command is 

/!$MS 
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If the !$ML (Long Map) control command is specified, the 
short map plus external references and all external defini- 
tions and their values including the libraries and permanent 
symbol toble are output. Double definitions, and definition 
declarations that were not given a value are flagged D 
and U, respectively. Unsatisfied primary references are 
flagged with UP, unsatisfied secondary references with US. 
The format of the command is 

!$ML 



The output of the l$MP control command is identical to 
that of !$ML, except that library definitions and references 
and the permanent symbol table are suppressed. The format 
of the command is 

/iSMP 



If relevant, information concerning the Public Library is 
also mapped. 



TCB The ! $TCB control command indicates (for a fore- 

ground task only) that the Overlay Loader must create a 
TCB and reserve a PSD location, and must generate a coll 
to RBM routine MrSAVE. MrFSAVE will be called if the 
set multiple precision mode exists. In addition, information 
to initialize the TCB at run time will be passed in the file 
header. If no !$TCB command is present, it is assumed that 
a TCB has been assembled into the root segment. Since the 
background TCB lies in protected memory, it cannot be as- 
sembled into the root of the background overlay cluster, but 
the necessary information is passed by the Loader to M:LOAD 
via the file header. Therefore, the TCB option applies to 
foreground tasks only. Multiple ! $TCB commands maybe 
used internal to the root program. Each !$TCB command 
would connect a separate interrupt function to the root pro- 
gram and be followed by ! $LD commands to load associated 
modules. The !$TCB may be followed by a !$BLOCK com- 
mand that would identify independent buffer blocks with its 
function. Individual temp stacks will be reserved by other 
than the initial l$TCB command that must precede the 
l$ROOT command. The format of the command is 



/iSTCB w^,w [,temp] 



2 are the values to be placed in words 1 and 2 
(f the created TCB (see "Real-Time Programming," 



w 
o 
Chapter 6). 



The Overlay Looders will handle specific and default cases 
of program execution and TCB initialization within the frame- 
work of the following restrictions: 

• The Overlay Loaders define all background Task Con- 
trol Blocks completely, using the value of the temp 
parameter on the !$ROOT card, load information, and 
the ! $BLOCK parameters. 

• In foreground tasks, if the user assembles the TCB as 
part of the program, it either must contain all informa- 
tion as data or as external references satisfioble at 
load time, or be initialized by the task itself. A trans- 
fer address is assumed to be a transfer to an initializa- 
tion section that will do any required housekeeping, 
arming, enabling, or triggering the task. If no trans- 
fer address exists, MrLOAD will arm and enable and, 
optionally, trigger the task using information in 
■words 1 and 2 of the TCB. 

• If the Overlay Loaders initializes the TCB by means of 
the TCB parameters, they do so completely, using load 
information and values on the ! $TCB and I $BLOCK 
cards. No partial initialization of a TCB is allowed 
with the exception of the blocking buffer pool. If a 
user builds his own TCB, the TCB must begin at the 
execution location plus the "temp" value specified 
on the ISROOT command. 

• For foreground tasks for which the Loader builds o TCB, 
the Loader will create the PSD reserve and a coll to 
M;SAVE. The user's root is then entered either at the 
location specified in the transfer address, or at the 
FWA of the root when the transfer address Is missing. 
The map will indicate a transfer address of "NONE" 
for the root. 

• Where multiple ! $TCB commands are used within the 
root program, the transfer address for the program is 
established by the modules preceding a second use of the 
!$TCB. FORTRAN generated programs do not provide 
a transfer address. If no transfer address exists, each 
subtask within the root program will be initialized by 
MrLOAD using the information In words I and 2 of 
their respective TCB. If a transfer address is provided, 
MrLOAD will not initialize any subtask. 

The user exits with either a call to the RBM routine MrEXIT 
or by a standard exit procedure. 

Public Library routines and Monitor service routines called 
by the user program will require temporary storage areas 
that are dynamically allocated at execution time. These 
temporary storage areas must be allocated in a fixed storage 
stack that is reserved by the Loader at load time on the 
basis of the temp parameter on the l$ROOT control com- 
mand. In addition, the Loader will insert in the TCB the 
first and last word addresses of the area. The temp area 
will be allocated preceding the root segment. It need not 
be a reserve in the module* 



temp defines the size of the temporary stack to be 

reserved for a TCB other than the initial TCB. 



For more information on initialization arvi structure of 
TCBs, see Chapter 6. 
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ROOT The !$ROOT command specifies that the modules 

that follow It constitute the root segment of the overlay 
cluster. A ! $ROOT command must precede all !$SEG com- 
mands, and may be followed by ! $LD, !$INCLUDE, 
!$EXCLUDE, ISTCB, l$LCOM, !$RES, !$MD, !$LIB, and 
l$LB commands, which cause the loading of those modules 
that form the root segment. Loading of the root will begin 
at the first cell following the temp stack for the background 
task. An execution bias may be specified. The user must 
ensure that the root segment, exclusive of any library load- 
ing, is less than 32K bytes. The root and its library are 
written as two records. Therefore, the library portion of 
the root may also be a maximum of 32K-1 bytes, which 
gives a maximum root size of approximately 32K words. The 
format of the command is 



!$ROOT[temp,exloc,oplb,n][,DT] 



reads only relocatable binary modules from the GO file and 
other input files specified on !$LD, ! $SEG, and I $ROOT 
cards. All files must be pre-positioned (GO is rewound by 
the Loader), and the modules must be in the same position 
on each file as calls on that file. The use of the IDNT on 
the !$LD card ensures the loading of the proper module. 
Note that the file must be positioned to the proper module 
in the file when the Loader reads from that file. Since 
there are no file-positioning control commands recognized 
by the Overlay Loader, each file must be constructed in 
correct sequential order. The form of the command is 



!$LD [oplb][,{;t"')][.DT] 



/here 



temp defines the size of the overlay cluster's tem- 
porary stack needed for the largest possible nesting 
of Public Library and Monitor service routines. 
The default size is 80 cells. If a TCB has been 
assembled into a foreground program, zero should 
be used for temp. 

exioc specifies the beginning location of the area 

in memory that the overlay cluster will occupy at 
execution time. The default case is KrBACKBG 
for a background task and K:NFFWA for a fore- 
ground task. The temp stack will be allocated at 
exIoc. 

oplb,n specifies that n modules are to be loaded 

contiguously from the operational label opib. 

DT specifies that calls to MrPUSH, MrPUSHK, 
M:PUSHC, M:PSHC, and M:RES are modified to 
dynamic-temp storage (in the calling sequence, 
"ADRL temp" is changed to "DATAO", and trail- 
ing reserve is stripped). This is done only for 
those ROMs (including library modules) loaded by 
this command. 



opIb is the operational label of the medium from 

which the binary module is to be loaded. The 
default case for an empty field is GO. 



fldentl 
Inm J 



DT 



ident is an EBCDIC representation of the 
IDNT of the program to be loaded. It is 
used for checking purposes only. If nm is speci- 
fied, it indicates the number of modules to be 
loaded from opIb; no check of any ident is made. 
If this parameter Is an ident, one module Is 
loaded. If empty, loading proceeds until an EOD 
is encountered. 



specifies that calls to MrPUSH, M:PUSHK, 
M:PUSHC, M:PSHC, and M:RES are modified to 
dynamic-temp storage (in the calling sequence, 
"ADRL temp" Is changed to "DATA 0", and trail- 
ing reserve Is stripped). This is done only for 
those ROMs (Including library modules) loaded by 
this command. 



Note that if the opIb parameter is absent, 1$LD (Load) or 
]$INCLUDE control commands must follow ! $ROOT to 
specify loading. If opIb is present but the n parameter 
is not, loading proceeds from opIb until an EOF status 
Is encountered. 



LD The !$LD control command Identifies one or more 

modules to be loaded as part of a segment. Each input file 
must be ordered in the same sequence as the !$LD cards in 
the control stack accessing that file. The Overlay Loader 



LB The I $LB command controls the search of libraries 
(for this segment only) to satisfy external references en- 
countered during the loading of modules forming the seg- 
ment. If the ! $LB control command Is omitted, the 
Overlay Loader will first attempt to satisfy all references 
by definitions in other segments of that path or from the 
root, and then will search the libraries specified by I $LIB 
or by the default cose. Individual !$LB cards supersede 
! $LIB or default for that segment only- Libraries are 
searched only on occurrence of a !$SEG or !EOD control 
command. 1$LIB and !$LB cards only set the mode and 
sequence of search . Only libraries on the RAD or disk pack 
may be loaded selectively using the J$LB command. To 
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inpuf "library" programs from other media, the user must 
use standard !$LD commands. The format of the com- 
mand is 

!$LB m,x[,y] 



where 



m specifies the search mode and is one of the fol- 

lowing EBCDIC codes: 

Code Search Mode 



B Basic (and Main) 

E Extended (and Main) 

M Main only 

x[, y] specify the order of library search and are 
either of the following EBCDIC codes: 

Code Library 



System 
User 



If y is not specified, only x will be searched. 
There are no default values for m, x, or y. 



INCLUDE The !$INCLUDE control command specifies 

external definitions in those library modules that are to be 
loaded with this segment, even though they are not refer- 
enced in the segment. Their definitions will be included 
in the Symbol Table for use by higher-level segments- 
More than one !$INCLUDE command may be used. Li- 
braries are searched according to a preceding ! $LB or I $LIB 
card or the initial default case. The format of the com- 
mand is 



SINCLUDE def,[,def-, . . . ,def ] 
' ^ n 



where def; is an external definition of a library program to 
be included in the segment. 

EXCLUDE The !$EXCLUDE control command inhibits 

library search and linkage for the named definition(s) even 
though an external reference occurs in a module of the seg- 
ment. The format of the command is 



ISEXCLUDE def,,def^,...,def 
I / n 



program, then excluding the one def is sufficient to fore- 
stall loading of its associated library module. 

MO The ! $MD (modify) control command is used to 

change core locations at load time before the absolute 
overlays are written out onto the OV file. I $MD commands 
must be inserted within a SEG sequence and apply only to 
the segment being loaded. A check is made that the 
effective address of the ! $MD command lies in the segment 
and that any labels used are defined for the path the seg- 
ment lies In. The Overlay Loader aborts if the modifica- 
tion location lies outside the limits of the segment. In- 
serted values are not tested for range. External symbols 
(definitions) used in loc or value must have been previ- 
ously defined. The format of the commard is 

!$MD loc,valueF,value,, value^, . . . ,value T 
•- I 2. n-* 



where 

loc specifies the execution location of the first 

modification, relative to the FWA of the current 
segment. 

value. is the hexadecimal quantity to be inserted 

at loc + i (for example, value is inserted at loc, 
value, at loc + 1, etc.). 

Both the loc and the value; parameters are subject to the 
restrictions set forth in "Control Command Format," i.e., 
hexadecimal notation must be indicated by a leading + or -. 
Note that it is not possible to modify a library module by use 
of an ! $MD control command. 

RES The IRES control command allows the user to re- 

serve an area at the end of the segment (root) program for 
run-time patching. The format of the command is 



iSRES def,size[,def,size], . . .[,def,size] 



where 
def 
size 



is the name of the area to be reserved, 

is a decimal value specifying the number of 
words in the reserve area. 



LCOM The !$LCOM control command allows the user 

to allocate labeled COMMON blocks within a segment 
(root) program. The format of the command is 

!$LCOM block,size[,block,sizej. . . [,block,size] 



/here 



where def. is the external definition for a library routine 
that is not defined along the current path. If def, is one 
of several definitions associated with a specific library 



block is the one-to-eight character EBCDIC name 
of the labeled COMMON block. 

size is a decimal value specifying the words to be 

allocated for the block. 
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SEG The !$SEG control command defines the modules 

that will form a segment. Numbers used to define a seg- 
ment must be unique. Segment identifier numbers need not 
be consecutive. A segment, including its library, is re- 
stricted too maximum of 65, 534 bytes provided enough 
background is available. 

Each !$SEG or !$ROOTcontrol command may be followed 
by !$LD, |$MD, !$INCLUDE, l$LIB, and !$LB commands 
to load the modules to form that segment. The loading for 
a segment terminates on a new l$SEG control command. 
The control command stack is terminated by an lEOD. The 
user may defer the loading of a specific library routine 
through the application of the !$EXCLUDE command. The 
Loader will attempt to satisfy all references present at a 
level from the libraries specified on I$LB, l$LIB, and 
!$INCLUDE commands or from the default library case. A 
given library is searched only once per segment. The 
format of the command is 

!$SEG si,sn[,oplb,n][,DTj 



/here 



si is a number less than or equal to X'FF' used to 

identify the segment being loaded. It will be 
used to call the segment at run time. 

sn is the number of the segment to which this seg- 

ment is attached. 

oplb,n specifies that n modules are to be loaded 

contiguously from the operational label opib. 

DT specifies that calls to M;PUSH, MrPUSHK, 
M:PUSHC, MrPSHC, and M:RES are modified to 
dynamic-temp storage (in the calling sequence, 
"ADRL temp" is changed to "DATA 0", and trail- 
ing reserve is stripped). This is done only for 
those ROMs (including library modules) loaded by 
this command. 

The following rules should be observed in defining segments 
for the overlay cluster: 

1. In OLOAD, the longest segment must fit into core with 
the Loader and its tables. If a segment is too long, it 
may be reassembled as two modules and loaded as two 
segments. 

In BLOAD, segments (and the root) are loaded one 
granule at a time, so that all background (less the 
space required by BLOAD and its tables) is available 
for symbol tables. 

2. The Loader will first attempt to satisfy library refer- 
ences using the Public Library and then will search the 
appropriate libraries on the RAD or disk pack. Using 
the 1$INCLUDE command, other often -used library 
routines can be loaded with the root where they will 
be accessible to all segments. However, library routines 



loaded in any segment will be accessible only to 
segments in the same path. 

Where segment content (not the root) is preceded by 
reserve area, such area does not consume space during 
the loading process. However, if a Labeled COMMON 
block is initially defined by the first module of a 
segment, it is considered a data area that will precede 
all reserve areas which will consequently consume space 
during Loader processing. 



PUBLIB (OLOAD only) The 1$PUBLIB control command 

indicates that the Overlay Loader is to create a Public Li- 
brary using modules that follow and/or modules from selected 
libraries. The Public Library is biased at the location specified 
in KrPLFWA of the RBM zero table. Each symbol is flagged 
as Extended, Basic, or Main according to control information 
on the ISPUBLIB card. However, a library may contain 
routines of more than one mode. Such identical definitions 
of different modes are differentiated in the Symbol Table 
(LIBSYM) and are not considered duplicate. 

When library routines are part of the Public Library, they 
must be reentrant and therefore must use the dynamic tem- 
porary stack (specified as the temp field on the j$ROOT 
command) for their temporary storage space. The loader 
will change the calling sequences of any calls to M:RES, 
MrPUSH, MrPUSHK, MrPUSHC, or M:PSHC to indicate dy- 
namic temporary stack; and will delete trailing reserve from 
ROMs containing these calls. 

A severity level of 1 is set if unsatisfied references or 
double definitions are encountered during the loading of a 
Public Library, and the library will not be written onto the 
PUBLIB file. When a Public Library is being created, the 
Overlay Loader creates a new Public Library on the RAD 
or disk pock. The Public Library just loaded is written 
onto the PUBLIB file in the User Processor area. The total 
length of the Public Library must not exceed 9191 words. 
The Monitor Services Transfer Vector (TVECT) file is read 
from System Processor area, and the Public Library section 
is updated and written onto TVECT. A new Public Library 
Symbol Table is written to LIBSYM file in the System Data 
area. The new LIBSYM is incompatible with the Public 
Library currently in core. All files are closed and nor- 
mal termination through M;TERM takes place. The new 
Public Library is then loaded into core by rebooting the 
RBM. The format of the command is 

!$PUBLIB library-mode[,oplb,n] 



mode mustbe one of the following EBCDIC codes: 
Code Mode 



B 


Basic 


E 


Extended 


M 


Main 



Control Command Repertoire 99 



A new !$PUBLIB control command must be pro- 
vided each time mode is to be changed. 

oplb,n specifies that n modules are to be loaded 
contiguously from the operational label opib. 

I$LD, l$LB, !$INCLUDE, and l$MD commands are hon- 
ored when using l$PUBLIB in the same manner as for the 
!$SEG command. !$ROOT, !$TCB, end l$SEG commands 
may not be used in conjunction with the !$PUB LIB command. 



END The !$END command is treated exactly like an 

!EOD command. Itshouldbe used in place of lEODwhen- 
ever multistep job stacks are to be prestored on a RAD file. 
The Utility COPY routine will not interpret this command as 
end-of-file (EOF). The format of the command is 

!$END 



LOADER ERROR MESSAGES 

The Overlay Loader program outputs messages on both OC 
and DO concurrently with the load operation. If OC and 
DO are assigned to the same device, duplication of mes- 
sages on DO is suppressed. The Overlay Loader error mes- 
sages are given in Appendix D. 



The format of the 'encoded' error messages is 



ERR XX 



where xx is a two-letter mnemonic that identifies the error 
(as described in Appendix D). 

The types of Overlay Loader messages are as follows: 

1. Warning messages (W), after which loading continues. 

2. Response messages (R), requiring an S or X key-in from 
the operator, in which case the message 



! .'BEGIN WAIT 



is written on OC. The operator activates the console 
interrupt and keys in either of the following codes. 

Code Meaning 

S Continue. 

X Abort Overlay Loader with code 'OP' 

and return control to JCP. 



3. Abort messages (A), upon which the Overlay Loader exits 
via the RBM routine MzABORT (see also Appendix D for 
abort codes, abort messages, and their meanings). 

The Overlay Loader 'plain text' error messages are largely self- 
explanatory but are also furtherdescribed in Appendix D. 
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8. RAD EDITOR 



The RAD Editor controls RAD and disk pack allocation by 
maintaining file directories for all resident standard areas. 
A resident standard area is one that has its area mnemonic 
in the RBM Master Directory (either as a permanent area 
defined at SYSGEN or a temporary area defined by the 
Mount key-in) and is not checkpoint (CP), background 
temporary (BT) area, or of any area whose mnemonic begins 
with the character X. (X identifies a nonstandard area. ) 
Through its control commands the RAD Editor can 

Add entries to or delete entries from file directories 



Copy data from one random file to another 

Maintain libraries in the system library (SL) and user 
library (UL) areas for use by the Overlay Loaders 

Copy an object module contained in a library 

Map file and library module allocations 

Dump contents of RAD files, RAD areas, or RAD-type 
devices in hexadecimal format. 

Save the contents of areas or files in a format restor- 
able by the RAD Editor, or save the contents of areas 
in a rebootable format on magnetic tape (which may 
also be restored by the RAD Editor) 

Clear an area or file 

Truncate a file or all files within an area 

Output messages to the operator 

Initialize file directories for new disk packs 

Flaw bad disk pack tracks and allocate alternates. 

The RAD Editor generates and maintains directories for the 
following permanent areas: 

System Processor area (SP) 

System Library area (SL) 

System Data area (SD) 

User Processor area (UP) 

User Library area (UL) 

User Data area (UD and aa) 



Size and location of each permanent area are contained 
in the RBM Master Directory. The RAD Editor allows map- 
ping of all areas, including Checkpoint and Background 
Temp areas, and the dumping of oil random-access files. 



STANDARD RAD/DISK PACK AREA ORGANIZATION 

Every area contains its own file directory. Each file is 
identified by a file directory entry that indicates the name, 
format, and location of the file. The areas and their file 
directories are software write-protected (at SYSGEN) and 
may have any of the following four write-protect codes: 

Code Meaning 

NO only files with a write-protect code of NO 

may be added to the area . 

BG only files with write-protect codes of NO 

or BG may be added to the area. Back- 
ground programs may write on any file in 
the area, but foreground programs may only 
write on files with NO write-protect codes. 

FG only files with write-protect codes of NO 

or FG may be added to the area. Fore- 
ground programs may write on any file in 
the area, but background programs may only 
write on files with NO write-protect codes. 

SY files with any write-protect codes may be 

added to the area. 

For areas with BG or NO write-protect codes, any RAD 
Editor control command may be used without the need for 
an SY key-in. However, for areas with FG or SY write- 
protect codes, the following RAD Edit control commands 
require that an SY key-in be in effect at the time the con- 
trol command is executed: 

I #ADD 

[^DELETE 

{^TRUNCATE 

{^SQUEEZE 

{^RESTORE 

!#CL£AR 

Space within an area is allocated sequentially; the first file 
in the area begins in the first sector following the first file 
directory. The second file in the area begins in the next 
available sector following the first file. Normally, as each 
file is added to the area, the next available sector is used 
as the start of the new file; however, the control command 
used to allocate space for the file may specify that the file 
begin on the next available track (or cylinder) boundary. 
In this event, any space bypassed will remain unused and 
the RAD Editor will not attempt to fit a new file into the un- 
used space. New files are always added at the end of the 
currently allocated space within an area. 
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when a directory entry (and, effectively, its corresponding 
file) is deleted, the area formerly occupied by the file is 
left unused. In normal operation, the RAD Editor makes no 
attempt to recover these unused areas. Therefore, the 
addition of a file may cause overflow of the permanent area 
although ample space may be available. However, RAD 
squeezing can be requested via an Editor ! ^SQUEEZE com- 
mand to overcome this problem. Squeezing recovers the 
unused storage within a permanent area by regenerating the 
directory and moving files. 

Before any permanent file can be written (using the Moni- 
tor routine MrWRITE), space must be allocated for the 
file. This is accomplished by requesting the RAD Editor 
to add o new entry ot the designated directory. Con- 
trol commands allow directory entries to be added or 
deleted. 

Warning: While processing the commands ADD, DELETE, 
~ TRUNCATE, SQUEEZE and CLEAR, foreground 

files that may become active are the user's 

responsibility. 

DATA FILES 

Ordinarily, data is not written in permanent files by the 
RAD Editor. Data files are normally written by user pro- 
grams- However, a RAD Editor control command can be 
used to copy data from one random-access file to another. 
Copied files may be temporary or permanent files. 

LIBRARY FILES 

System and User Library files, which are searched by the 
Overlay Loaders for external references, are generated and 
maintained by the RAD Editor (the only processor that 
writes in these files). 

A library area (either the System Library area or the User 
Library area) contains six files: 

1. Module Directory File (directory of library modules). 

2. EBCDIC File (list of all library definitions/references). 

3. Extended DEF/REF File (index to extended precision 
definitions/references in EBCDIC file). 

4. Basic DEF/REF File (index to standard precision 
definitions/references in EBCDIC file). 

5. Main DEF/REF File (index to main definitions/ 
references in EBCDIC file). 

6. Module File (library object modules). 



The extended and basic DEFAEF files (items 3 and 4) are 
optional. 

These fifes are generated and maintained from information 
in control commands and object modules placed in the 



library by the RAD Editor. Special commands are supplied 
to allow the addition and deletion of object modules; these 
control commands will cause the six files in the RAD Li- 
brary area to be updated. A control command allows an 
object module contained in a library to be copied onto BO. 

Any random-access or sequential-access file (either tem- 
porary or permanent) can be dumped on LO. 

The RAD Editor con save the contents of a permanent area 
and the RBM bootstrap in a self-reloadable form. The 
saved image contains a bootstrap loader, the execution of 
which restores the RBM bootstrap and the permanent area 
on the RAD or disk pack. 

Updating or squeezing of permanent areas and library files 
that contain information for real-time programs must not 
occur while the foreground is using these permanent areas 
or files. The user must ensure that the RAD Editor is not 
modifying a permanent area while a foreground program is 
using it. 

The names for the library files must be one of the following: 



Code 



File 



MODIR Module Directory 

EBCDIC EBCDIC 

EDFRF Extended DEF/REF (optional) 

BDFRF Basic DEF/REF (optional) 

MDFRF Main DEF/REF 

MODULE Module 

The DEF/REF file needs to be added only as required. The 
System Library (SL) requires only the MDFRF file. 



ALGORITHMS FOR COMPUTING LIBRARY FILE SIZES 

The following algorithms may be used to determine the 
lengths of the six files in a library area: 

The number of granules in the MODIR file is 
MODIR = tOUL 



is the number of modules to be placed in the 
library (including main, extended-precision, and 
single-precision routines), i must be equal -to or 
less-than 1023. 

is the granule size in words. 
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The number of granules in the EBCDIC file is 



The number of granules in the MDFRF file is 



EBCDIC 



4(1 +cl) 



where 
d 



is the number of unique DEFs and REFs in the 
library (including main, extended-precision, and 
single-precision routines), d must be equal -to 
or less-than 8191. 



g is the granule size in words. 

The number of granules in the EDFRF file is 



2 + Z)(2 + r +d ) 
i=l -2 ^ 



EDFRF 



MDRFR 



n 
2H-X;(2 + r +d) 



where 

n is the number of routines in the main library. 

r. is the number of REFs in the jth library routine 

' in the moin library. 

d. is the number of DEFs in the jth library routine 

in the main library. 

g is the granule size in words. 

The number of records in the MODULE file is 



/here 



n is the number of routines in the extended- 

precision library. 

rj2 is the number of REFs in the extended-precision 

library. 

dj2 is the number of DEFs in the extended-precision 

library. 

g is the granule size in words. 



MODULE = y\ (c.) 
n .^1 I 
I - I 



where 



n is the number of modules in the library (includ- 
ing main, extended-precision, and single- 
precision routines), and n must be equal to or 
less than 1023. 

c. is the number of record images in the Ith library 

routine. 



The number of granules in the BDFRF file is 



2+£(2+r. +d.) 



BDFRF 



k=l 



k "k' 



/here 



n is the number of routines in the single-precision 

library. 



r, is the number of REFs in the kth library routine 

in the single-precision library. 

d, is the number of DEFs in the kth library routine 

of the single-precision library. 



g is the granule size in words. 



RAD EDITOR OPERATIONAL LABELS 

The RAD Editor uses the temporary background operational 
labels XO through X6. These labels must not be assigned at 
the time the IRADEDIT control command is executed, nor 
may they be used on I^DUMP or I^FCOPY commands. 

The following labels must be assigned before requesting the 
RAD Editor: 

Label Explanation 



BI 



BO 



CC 



Object module input (and Restore) to System 
and User Library. 

Object module output (and Save) from the 
System and User Libraries. 

Control command input, if KP is in effect, 
control command input is read from opiabel 

•oc. 
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Label Explanation 

DO Log of error messages and operator key-ins. 

LL Log of control commands. 

LO Maps of directories and dumps of files. 

OC Messages to the operator and key-ins from 

the operator. Control commands are read 
from OC if a "KP" key-in is In effect. 



CALLING RAD EDITOR 

The RAD Editor is requested with a IRADEDIT control com- 
mand. The IRADEDIT control command Is read from CC 
and causes the root segment of the RAD Editor program to 
be loaded into core memory from the RAD. It has the format 

IRADEDIT 



Reading an !EOD from CC causes the RAD Editor program 
to return control to the Monitor. If CC is assigned to 
magnetic tape or a RAD file, an EOF condition encoun- 
tered while reading control commands from CC will cause 
the RAD Editor to return control to the Monitor. The form 
of the command Is 

lEOD 



CONTROL COMMAND FORMAT 

All RAD Editor control commands are Input from CC (or 
from OC if a "KP" key-in is in effect) and listed on LL. 
The general format Is 



l*menmonic specification 



where 
I 



identifies the record as a control command. 



J£l indicates that the control command is unique to 
^ ^ the RAD Editor. 



mnemonic Is the code name of a RAD Editor com- 

mand immediately following the !* characters. 

specification is a series of required or optional 

parameters unique to the specific command. The 
conventions used in specifying parameters are 
(T) a string of up to five decimal digits, having 
a value less than 65,535, denotes a decimal in- 
teger; (2) a string of the form +xxxx is treated as 
hexadecimal; (3) all other strings are assumed to 
be nonnumeric. 



One or more blanks must separate the mnemonic and speci- 
fication fields, but no blanks may be embeddded within a 
field. An empty parameter In the specification field Is 
denoted by a comma. However, commas may be omitted 
for empty trailing parameters. A control command is 
terminated by the first blank after the specification field. 
If the specification field is absent and a comment follows 
the mnemonic field, the command is terminated by a period. 

The first two characters of the mnemonic portion of the 
command are sufficient to define the command; the re- 
maining characters may be omitted since they are Ignored 
If they are present. 

In the descriptions of the following Individual commands, 
certain terms are used that have specific meanings for the 
RAD Editor. The terms ore: 



Term 



filename 



identification 



I ibrary 



Meaning 

The two-character alphanumeric 
mnemonic for a resident standard area. 
The area rnnemonic must be currently 
present in the RBM Master Directory 
and, generally, may not be BT, CP, 
or Xn. 

For the commands !*LADD, 
I^LREPLACE, ! '^'LDELETE, !#LC0PY, 
!#LMAP, and I^LSQUEEZE, area must 
be either SLorUL. If neither is speci- 
fied, SL is assumed by default. 

Three to eight alphanumeric characters 
denoting a file contained within (or 
to be added to)an area file directory. At 
least one character must be alphabetic . 

The library routine name denoted by , 
the Extended Symbol IDNT directive, 
which is located in the start module 
load item of an object module. 

An object module library (within the 
System or User Library) denoted by one 
of the codes 

Code Library 



M 


Main 


E 


Extended 


B 


Basic 



For the commands I^LADD, 
!#LREPLACE, and l^LDELETE the de- 
fault library Is M (main). 



CONTROL COMMAND REPERTOIRE 

ADO The !*ADD command odds a new entry to the 

specified permanent file directory. It defines the nome. 
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size, record length, format, and write protection for the 
new file. It may also declare that the file will contain 
a resident foreground program, and will be maintained start- 
ing at a cylinder or track boundary. Space is allocated for 
the new file and the first sector of the file is set to zero 
if it has random format. The form of the command is 



!#ADD area,filename,P'-'- ) ,( ^ } 
InrecJ I srec J 



[,filefmt] 



c 



I] 



f-^rlEra] 



/here 



ALL indicates the file will be allocated to extend 

to the end of the area. After an EOF has been 
written on the file, it may be truncated to recover 
the unused space. 

nrec is the number of records in the file and may 

not exceed 65, 535. 

S indicates that the record size is equivalent to 

sector size and that nrec is to be used to determine 
the number of sectors to reserve, 

srec is the maximum number of bytes per record 

which must be even and may not exceed 65,534. 
If filefmt is R, srec is used as the granule size. 
The following default values are provided, depend- 
ing on the file format. 

Default Record Size 

• 120 for file format, B and P 

• Sector size, in bytes, of the device contain- 
ing the area for file format R or U 

• 80 for file format C, Since compressed files 
may contain records of variable length, this 
value is used for allocation purposes only. 
The S character may be used to force the 
allocation of a specific number of sectors for 

a compressed file. In this case, nrec indicates 
the number of sectors to reserve for the com- 
pressed file. 

filefmt is the structure of the file, as denoted by 

one of the following codes: 

Code Format 



blocked sequential -access file with a 
fixed record size 

blocked (and compressed) sequential ac- 
cess file with a variable record size 

blocked (packed) random access file, 
fixed record size 

unblocked random access file 

unblocked sequential access file. 



If the format parameter is omitted, the default for- 
mat is determined by the area mnemonic as follows: 

Default Area Mnemonic 



R 



B 



SP,SL,UP,UL,FP,BP 



any o 



ther 



wp specifies the write-protection level for the file, 

as denoted by one of the following codes: 

Codes Write-Protection Level 

NO (or N) No write-protection; background 

or foreground programs may write 
on the file. 

BG (or B) Write permitted by background 

programs only. 

FG (or F) Write permitted by foreground 

programs only. 

Background programs may write on 
the file if an SY key-in is in effect. 

SY (or R) Write permitted by RBM only. 

Foreground or background programs 
may write on the file if an SY 
key-in is in effect. 

If the wp parameter is omitted, the default write- 
protection level is NO. 

RF or F specifies that the file will contain a resi- 

dent foreground program that isto be automatically 
loaded at boot time, and therefore the area mne- 
monic must be SP, UP, or FP (the order of search). 

CYL specifies that the BOT of the file is to be 

allocated and maintained on a cylinder boundary 
if the area is on a disk pack. 

TRK specifies that the BOT of the file is to be 
allocated and maintained on a track boundary. 

DELETE The ! "DELETE command deletes on entry from 
the specified permanent file directory. The space formerly 
allocated to the file becomes unused. The space is recov- 
ered if the file being deleted is the lost file in the area. 
The Form of the command is 



l^DELETEarea 



Ei: 



1 1 enamel j 
area jj ' 



If no filename is specified, all files in the area are deleted. 
If there are active files in the area, the operation is not per- 
formed. Under no condition can the SParea be deleted. In- 
stead, the following messages are output 



##OPEN FILES, NO CHANGE: area, filename 



NO CHANGE: area 



If the write-protect code for the area is SY or FG, the SY 
key-in must be in effect at the time the control command is 
executed. 
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FCOPY The [^FCOPY (File Copy) command copies data 

from one random-access file to another. The file copy pro- 
cess terminates when EOF is encountered on an input file or 
when an end-of-tape is encountered on either the input or 
the output file. The form of the command is 



#FCOPY oplb-,oplb. 



/her 



opibj is the operotional lobe! or FORTRAN device 

unit number (e.g., F:109) of a temporary or perm- 
anent random-access file. The Utility COPY 
Routine (see Chapter 9) must be used to copy 
sequential-access files. 

opib] is the input file. 

oplb2 is the outpuf file. 

DPCOPY The !#DPCOPY (Disk Pack Copy) control 

command copies data from one disk park or cartridge disk 
to another. The entire contents of the pack or cartridge is 
copied and a checkwrite is performed on the copied data. 
The form of the command is 



l^DPCOPY +device^,-hJevice, 



where 

device] is the hexadecimal device number of the 

disk pack 

device2 is the hexadecimal device number of the 

disk pack to copy to, which may not contain any 
currently "mounted" areas. 

Note ; The bootstrap record is not copied to sector zero. 
The INITIALIZE command always writes the 
bootstrap record to sector zero. 

LADD The ! '^LADD (Library Add) command adds on 

object module to the designated library. The object 
module is read from BI, checked for sequence and checksum 
errors, and stored in the Module File within the library. 
From the data in the object module and on the control com- 
mand, the information about the module is extracted and 
placed in the Module Directory File (MODIR), the EBCDIC 
File, and one of the three DEF/REF Files (either MDFRF, 
BDFRF, or EDFRF File) as indicated in the library param- 
eter. BI may be assigned to any device; if BI is assigned 
to the RAD, it must be sequential file. The object mod- 
ule on BI must be in standard object language. Any blank 
card or binary card on BI that contains only zeros is ignored. 
The form of the command is 



! #LADD [area,][ident][,library] 



where ident is the program name located in the start module 
item of the object module on BI. 



The library routine may be selectively added to the SLorUL 
area from a file of library routines. If the identification 
parameter is omitted, all object modules on BI will be added 
to the library up to, but not including, the file mark or EOD 
on BI. 

Within a permanent area (SL or UL), each object module 
ident must be unique except as follows: an object module 
ident in the Main library cannot exist in either the Basic or 
Extended library. An object module with the same ident can 
exist in both the Basic and Extended libraries. 

If identification is present, the start module load item of 
the first program read from BI must be the same as shown by 
the identification parameter. 



LREPLACE The l#LREPLACE (Library Replace) command 
replaces an object module of the same identification in the 
designated library. The object module is read from BI and 
checked for sequence checksum errors. The object module 
on BI must be in standard object language. Any blank card 
or binary card (on BI) that contains only zeros is ignored. 
The form of the command is 



l#LREPLACE [areajident[,library] 



where ident is the program name located in the start module 
item of the object module on BI. The object module on 
BI replaces the module in the library having the same 
identification. 



LDELETE The I^LDELETE (Library Delete) command 
deletes an object module from the designated library. The 
form of the command is 



I #LDELETE [area,] ident [,library] 



where ident is the program name of the object module to be 
deleted. 



LCOPY The 1 ^LCOPY (Library Copy) command copies 

an object module from the designated library onto the BO 
device. The form of the command is 



I #LCOPY [area,] ident 



where ident is the program name (located in the start module 
item) of the object module to be copied onto the BO device. 

LSaUEEZE The l#LSQUEEZE (Library Squeeze) com- 

mand will squeeze designated library areas. Unused space 
is recovered by regenerating the directory files and 
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squeezing (compacting) the module file. The form of the 
command is 

!#LSQUEEZE[area] 



MAP The !*MAP command causes the specified direc- 

tories to be mapped on LO. For each permanent RAD area, 
the beginning and ending RAD addresses for the area are 
mapped. For each file, the contents of the directory entry 
describing the file are printed. This information includes 
name, format, write-protection, foreground task indicator, 
beginning address, EOF address, and EOT address for each 
file. For files on disk packs, the map also includes the 
cylinder/track/sector values for BOT. For files on RADs, 
the map also includes the track/sector values for BOT. The 
form of the command is 



! #MAP [area,] [,area_] . . . [,area ] 



where area must be a currently defined area. If no area 
parameter is included, all currently defined areas are 
mapped. 



LMAP The !*LMAP command causes the library files of 

the specified areas to be mapped on LO. For each area, 
the beginning and ending addresses for the area are mapped, 
followed by a map of the library files in the area. The 
library map includes the following Information for each 
routine: 

Library B (basic), E (extended) or M (main) 

Identification of routine 

Length of routine in words 

Sectorwithin the MODULE file that contains the routine 

DEFs in the routine 

REFs in the routine. 

The form of the command is 



EOT, or by having dumped the requested numberof records 
whichever occurs first. The form of the command is 



!# LMAP [area [,area]] 



DUMP The !#DUMP command dumps a RAD file, a RAD 

area, or a RAD-type device in hexadecimal format on the 
LO device. Records are dumped beginning with the first 
record of the file (record 0) unless an optional starting rec- 
ord number is given. The dump is terminated by an EOF, 



!#DUMP 



opibi 

area [, fi lename] 

-i-devi ce-number . 



r, start [, number]] 



opIbI is the operational label or FORTRAN device 

unit number (e.g., F:I09) assigned to a RAD file. 
Operational labels XO through X6 may not be used 
because they are reserved for use by RADEDIT. 

device-number is the hardware device number of 

the RAD or disk device. This number must be 
preceded by a + (plus character) and must match 
a RAD or disk device number input at SYSGEN. 

start is the relative record (or sector) number at 

which the dump is to begin. For RAD files, this 
number represents the record relative to the first 
record of the file. For RAD areas, it represents 
the sector relative to the first sector of the area. 
For device-number, it represents the sector rela- 
tive to the first sector of the device. If start is 
omitted, the dump begins at the first record rela- 
tive to the BOT of the file, area, or device. 

number is the number of records (or sectors) to be 

dumped. If number is omitted, the file, area, or 
device is dumped until an EOF or EOT is encoun- 
tered. If the file format is random (R) or packed 
(P), the EOF is ignored. 

SAVE The !*SAVE command saves the contents of areas 

of specific files. Each file is written on the BO device, 
along with all pertinent information about the file. The BO 
media may be magnetic tape, unblocked file, paper tape, or 
cards. Ifthe media ismagnetic tape and an end-of-reel condi- 
tion occurs, the operator is expected lo mount the next reel to 
be used for output. If the medio is paper tape and an {ATTEND 
command has been input for the current job, the message 



nnnn FT. OK? 



will be output on the OC device. If there is more than nnnn 
feet of paper tape available, the operator is expected to 
type in Y. This process will continue until all files speci- 
fied by the !*SAVE command have been output, or until 
the operator determines that the required amount of tape is 
not available. Any input other than Y causes the pro- 
gram to output an end-of-reel record followed by blank 
trailer. The program then outputs the message 



! "BEGIN WAIT 



on the OC device. The operator must then mount a new reel 
of tape, interrupt, and key-in S. The program then out- 
puts blank leader, a save-continuation record, and proceeds 
as described above. 
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The BOoutput can be restored via the 1*^ RESTORE command. 
The form of the command is 

/!#SAVE[FILEj[area]rf°7; 1..1... " 

■'I Ifilenamej J 



where FILE indicates that the output format contains all 
necessary mformation for the restoration of specific files. 
Each file saved is followed by an !EOD (or file mark in the 
case of magnetic tape). If another I '^ SAVE FILE control 
command follows immediately, the additional files are ap- 
pended to the previous output. 

Note; I* SAVE FILE command does not save the following 
files from the SP and SD area: 

SP,BOOT 

SP, RBM 

SP,TVECT 

SP,RADEDIT 

SP,OLOAD 

SD,RBMGO 

SD/RBMOV 

SD,RBMAL 

SD,ERRFILE 

SD,RBMID 

SD,RBMSYM 

SD,RBMPMD 

When a control command is encountered that is not a 
pSAVE FILE command, an additional EOF is written and 
the BO device is rewound before the next command is 
executed. 



RESTORE The !#RESTORE command restore the contents 
of areas or specific files that have been saved via the 
!*SAVE command. The files are selectively restored from 
the BI device. The form of the command is 

!%ESTORE[area[|°7° I . . 1 , . . .] 
MfilenameJ I -• 



If the file being restored does not have a corresponding en- 
try in the area file directory, a new entry is made and the 
file is copied into its allocated region. If the file being 
restored already has an entry in the area file directory the 
file will be copied into the currently allocated region unless 

• There is a format conflict 

• The allocated region is too small 

• The proper level of write authorization is not in effect, that 
is, SY key-in not performed and file is write-protected. 

If an end-of-reel condition is encountered while reading 
from BI the operator will be requested to mount the next reel 
in sequence, as created by the j^SAVE command. 

If the BI input is a rebootable save tape, no filenames may 
be specified —each area is restored in its entirety. 

SQUEEZE The !#SQUEEZE command compacts the desig- 

nated fi le areas. Unused space is regai ned by regenerating the 
directoriesand moving files. The form of the comrriand is 

{'^SQUEEZE area[,area]. .. [,area] 



The FILE keyword may be omitted only if the BOoperational 
label is assigned to magnetic tape, causing a bootstrap pro- 
gram to be output on BO followed by the contents of the 
specified areas. No filenames may be specified in this 
case, since the allocated portion of an area is saved as if 
it were a single file. The specified areas are followed by 
two file marks and the tape is rewound. 

When the output magnetic tape is booted, the bootstrap 
program will restore the saved areas and then initiate an 
RBM boot process. 

The user must not mix the output of the I^SAVE command 
with the PS AVE FILE command on the same magnetic tape. 



VERIFY The !# VERIFY command checks the output of 

the !*SAVE command to ensure that it can be correctly pro- 
cessed by {^RESTORE at a later time. The form of the com- 
mand is 



!# VERIFY [opibi] 



where opIbI is the operational label of the medium from 
which the I^SAVE output is to be read. If no opIbI is pres- 
ent, fhe opfbl BO is assumed hy default". 



The areas BT, CP, and any area beginning with the letter X 
are never squeezed. An explicit request to squeeze any of 
these is ignored. If the area being squeezed contains a file 
that is assigned to an operational label and the file can be 
moved, the following message will be output. 



** OPEN FILE, NO CHANGE: area,filename 



File is not moved and squeezing continues. 

File directory information may be destroyed if an area being 
squeezed contains a file that is assigned to an operational 
label being used by an active foreground program. 

Care shouldbe exercised when SQUEEZE ing areas that may be 
currently in use by foreground programs in order to avoid file 
conflicts. 



CLEAR The I^CLEAR command zeros out the specified 

RAD area or file. The form of the command is 



!#CLEARarear,|!'.7° }1, 
nfilenameJJ 



108 



Control Command Repertoire 



If no filename is specified, all files In the area are cleared, 
including file directories. If there are open files in the 
area, the operation will not be performed. Instead, the 
following message will be output 



## OPEN FILE, NO CHANGE: area, filename 



If the write-protect code for the area is SY or FG, the SY 
key-in must be in effect at the time the control command is 
executed. 



BDTRACK The I'^BDTRACK command specifies the disk 

pack and the track numbers for which alternates are to be 
provided. 

Two methods of selecting alternate tracks are used: the 
flawed headers and the bad track list. 

The disk packs. Models 7242/46, use flawed headers. The 
original track will have its headers rewritten with a flaw 
mark and a reference to the alternate track. The headers 
of the alternate track will be rewritten to refer to the 
original frock. The cartridge disks. Models 3231/32/33 and 
7251/52, utilize a bad track list which is written on cyl- 
inder 0, track 0, sector 2. The bad track numbers are written 
into the list and the corresponding alternate tracks ore se- 
lected during the read-write process. The form of the com- 
mand Is: 



!# BDTRACK 4dn, 



ALL 



+number£, +number]. . . [, +numberj 
decimal [,decimalj, . . [, decimal] 



where 

dn is the device number of the disk pack. 

number is the hexadecimal track number on the de- 

vice starting with 0. 

decimal is the decimal track number on the device 

starting with 0. 

ALL indicates that a bad track list is to be con- 

structed from the flawed headers previously written 
on the 323x device. Once this is done, !#BDTRACK 
commands can be used to enter track numbers into 
the bad track list on the device. 

Note: See the Unsolicited Control section as to how 
bad track lists are entered (Mount) and re- 
moved (Remove) from the system tables. 

Example: 

/ 

I # BDTRACK +E5, +325, +297 



GDTRACK The !#GDTRACK command specifies the disk 

pock and the track numbers for which alternates are to be 
eliminated. This may be used if it is suspected that a desig- 
nated flawed track is good. 

On the disk packs. Models 7242/46, for each track spec- 
ified, its headers will be rewritten to clear the flaw mark 
and the headers of the assigned alternate track will be re- 
written to free the alternate track. 

On the cartridge disks. Models 7251/52 and 3231/32/33, 
which utilize a bad track list, a "blank" bad track Ir-st can 
be written on cylinder 0, track 0, sector 2 of the device 
using the "ALL" option. If a bad track list exists on the 
device, bad tracks can be eliminated as described above. 
The form of the command is: 



!#GDTRACK +dn 



ALL 

+ number[, + number] .. . [, + number] 

decimal [,decimal]. . . [,decimal] 



dn is the device number of the disk pack. 

number is the hexadecimal track number on the de- 

vice starting with 0. 

decimal is the decimal track number on the device 

starting with 0. 

ALL indicates that a "blank" bad track list is to be 

written on the device. 



INITIALIZE The !#INITIALIZE command provides disk 

pack serialization (including date) and allocation of data 
areas. The form of the command is 



{^INITIALIZE +dn[, serial-number], DO 



dn is the hardware device number of the disk pack 

to be initialized. The device number must match 
a disk pack device number input at SYSGEN. 

serial number is any combination of eight characters, 

excluding blanks or commas. If the disk pack is 
Xerox Model 7242 or 7246, the serial number is 
written on cylinder 202, track 19, sector 0, to- 
gether with the current date. For Xerox Models 725x 
and 323x, the serial number and date are written 
on cylinder 0, track 0, sector 1. 

DO Indicates that the file directory on the device 

Is not to be initialized. 
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The l^INITIAUZE command may be followed by a set 
of oreo definition cards that hove the formot 

I *area=trocl<s[Avp} 



where 



area is on orea mnemonic from the following list: 

SP BP SL UP 

SD CP BT UL 

FP SK (skiptrocks) aa 

tracks is the number of trocks to be allocated 
for the area. A parameter of 'ALL' allocates 
all the remaining tracks on the device, 

is the write -protect code to be used for the 
oreo . This code is tested whenever any of the 
following operations are performed: 



wp 



ADD 
CLEAR 



DELETE 
RESTORE 



SQUEEZE 
TRUNCATE 



See "Standard RAD/Disk Pack Area Organization" 
for write-protect codes. 



MESSAGE The !*MESSAGE control command writes 

messages to the operator on the OC and LO devices. The 
form of the command is 



[*^MESSAGE message 



where message is any EBCDIC character string up to a full 
card image. 



PAUSE The ! "PAUSE control command causes a message 

to be written on the OC and LO devices followed by a wait 
for the operator's response. The form of the command is 

/ ■ 

!*^ PAUSE message 



where message is any EBCDIC character string up to a full 
card image. The format of the output is: 

!^ PAUSE message 
II BEGIN WAIT 

It is necessary for the operator to activate the control panel 
INTERRUPT switch and key-in an S to continue. 



TRUNCATE The !#TRUNCATE command eliminates un- 

used space from the end of specific files by setting the 
EOT pointer equal to the EOF pointer. If an EOF has not 
been written on the file, the file EOT will not be changed. 



All compressed files or files contoining programs loaded by 
the Overloy Loaders (or with the AAonitor f ABS command) 
will hove an EOF pointer. The space is recovered if the file 
being truncated is the last file in the area. The form of the 
commcmd is 



(^TRUNCATEareo 



r|fJlerKimeij' 



If no filename is specified all files in the areo containing 
an EOF ore to be truncated to the EOF. If the oreo is SD 
and no filename is specified, the following message will be 
output on the DO device and the OC device (if KP is in 
e ff ect ) and prov idi ng oplobe I s ore no t assigned to some dev i ce . 



## NO CHANGE: SD 



If the write protect code for the area is SY or FG, the SY 
key-in must be in effect at the time the control command 
is executed, 

END The PEND command is used exactly like the {EOD 

command; that is, it transfers control from the RAD Editor 
to the Monitor. The form of the command is 

!#END 



This command should be used in place of I EOD whenever 
multistep job stacks are to be prestored on a file. The 
Utility COPY routine will not interpret this command as 
an EOF. 



RAD EDITOR MESSAGES 

The RAD Editor program issues the error messages listed in 
Appendix D (Table D-4)on DO. If a KP key-in is in effect, 
the error message is output on OC and DO unless OC and DO 
ore assigned to the same device. The warning (W) messages 
in Table D-4 ore written on the OC and DO devices to 
provide a record of operations not performed or of critical 
operations in process. If an operator response is required, 
the R-type error message is followed by the RBM message. 



II BEG IN WAIT 



written on OC. The operator activates the PCP interrupt 
and keys in one of the following: 

Key-In Meaning 



SY,S 

S 

X 



Suspend disk write-protect and continue. 

Continue. 

Abort RAD Editor and return control to RBM. 



RAD Editor initiated aborts are identified by the abort 
code 'RE'. If the abort is operator-initiated, this Is indi- 
cated by the abort code 'OP*. 



no RAD Editor Messages 



9. UTILITY 



INTRODUCTION 

The Utility program operates in the background under the 
Real-Time Batch Monitor. It contains routines that: 

• Copy variable-length binary or EBCDIC records from 
one medium to another (Copy). 



Dump records onto an output device in either hexa- 
decimal or EBCDIC format (Dump). 



• Generate or update files that contain Xerox Standard 
Object Language modules (Object Module Editor). 



Generate or update symbolic files (paper or magnetic) 
that contain source data (Record Editor). 



• Edit card images by sequence number (Sequence Editor). 

Routines in the Utility program are device-independent. 
Utility handles anyblocked or unblocked, sequential -access 
RAD file. Use of a sequential -access RAD file is similar to 
that of a magnetic tape, as it has a beginning-of-tape, an 
end-of-file (if one has been written), and an end-of-tape. 
Note, however, that a sequential -access RAD file cannot 
be forward -spaced or backspaced over more than one file 
mark. A rewound sequential -access RAD file is positioned 
at beginning-of-tape. For both blocked and unblocked 
files, a record skip is a logical record skip. 



UTILITY PROGRAM ORGANIZATION 

The Utility program consists of two major sections: the Util- 
ity Program Control routine (always resident when the Utility 
program is operating), and the currently operating Utility 
subroutine. The Utility Program Control routine contains 
four interdependent elements: 

1. The Program Executive, which initializes the program 
(upon entry from RBM), interprets the ! UTILITY con- 
trol command (explained in "Calling Utility"), exer- 
cises control over the flow of control commands, handles 
normal and abort exits to the Monitor, and performs 

all I/O checking for the Utility program. 

2. The Source Input Interpreter, which reads and scans 
Utility control commands for the Control Function Pro- 
cessor and the current Utility subroutine. 

3. The Control Function Processor, which executes con- 
trol function commands common tool I Utility subroutines. 



4. The Operator Communication routine, which outputs 
messages toOC and DO and receives key-in responses. 

UTILITY PROGRAM EXECUTIVE 

When RBM reads a ! UTILITY control command control is 
transferred to the Program Executive routine. The lUTILITY 
control command is then scanned for parameters. If the 
name parameter is omitted (see "Calling Utility" below), 
it is assumed that only the Control Function Processor will 
be used. Utility control commands are read from the source 
input (SI) device unless a KP key-in is in effect, in which 
case commands are read from OC. 

If a specific Utility subroutine is requested, the Program 
Executive verifies that the subroutine is in storage; if 
not, an error message is written and an exit to RBM is taken, 
terminating the background operation. If the subroutine is 
present, initialization of. tables and flags occurs. 

The Program Executive then transfers control to the requested 
Utility subroutine. The Utility subroutine uses the Source 
Input Interpreter to read all commands, and uses the Control 
Function Processor to execute control functions. All other 
control commands are interpreted and executed by the Uti- 
lity subroutine itself. 



SOURCE INPUT INTERPRETER 

The Source Input Interpreter, which is called by the Program 
Executive routine, processes all control commands that are 
read by the Utility program. Utility control commands are 
input from the SI device (unless a KP key-in is in effect) 
and listed on the LL device as they are interpreted. 

Upon reading a command, the Source Input Interpreter de- 
termines whether the command is valid. If the syntax for a 
command is invalid, the following message is writtenon OC 
and DO: 



** INVCTL 



The Utility program then reads the next command or enters 
the wait state if attend mode is in effect. 

If the command is valid, it may be interpreted and executed 
either by the Utility subroutine or by the Control Function 
Processor. 



CONTROL FUNCTION PROCESSOR 

The Control Function Processor interprets and executes com- 
mands that are common to all Utility subroutines. If any of 



Utility m 



the controt commonds interpeted and executed by the 
Controf Function Processor contains an invatid operotionaJ 
fabef, the folfowtng message is output; 



** INV OPLB 



The Uti lity program then reads the next commond or enters 
the watt state if attend mode is in effect. 



CALinmumtTY 

The Utility program is requested vio o [UTILITY control com- 
mand, which causes the root segment of the Utility program 
to be loaded into core memory from the RAD. The FUTILITY 
control command has the for mot 

FUTILITY [rKime][, parorrMsterJ 



CONTRfIL ROUTIliE OPEIUTIOIfAL tABELS 

Four operationol labels are reserved for the Program Control 
routine. Their use is restricted to the functions below; they 
may not be used in place of the labels required by the vari- 
ous Utility subroutines explained later. 



Label Explanation 

SI Device for Utility control commond input, and 

various modtftcatton source inputs. (If o KP 
key -in is in effect, control commands ore read 
from OC. ) 



DO Device for listing of messc^es, error coruJitions, 

operator responses, etc. If OC and DO are 
assigned to the some device, duplication of 
messages is suppressed. 

LL Log of control commonds. 



OC Device for messages to the operator, key-in re- 

sponses from the operator (always via the keyboard/ 
printer), and control -commond input if a KP 
key-in is in effect. 



X5 Temporary RAD file used for prestoring commands 

read from SI. 



Utility functions ore generally executed dynamically; that 
is, control commands are interpreted and executed os they 
are read. However, when several operational labels ore 
assigned to the same device-file as SI, it is impractical to 
execute dynamically. In this case, commands must be pre- 
stored to avoid confusion with doto from that device. This 
decision to prestore is mode by the Utility progrom with one 
exception: the !*PRESTORE control command allows the 
user the option of prestoring control command input until 
on EOD card image is encountered. For RBM Utilities, pre- 
stored commonds ore written on o temporary RAD file (using 
operational label X5) and read from the RAD for interpreto- 
tion and execution. 



where 

name is the name of a Utility routine or may be 
omitted. It may be any of the following: 

COPY (Copy) 

DUMP (Dump) 

OMEDIT (Object Module Editor) 

RECEDIT (Record Editor) 

SEQEDIT* (Sequence Editor) 

parameter represents the series of optional param- 
eters that are unique to each Utility routine. Po- 
rometers are fully exploiried in the description of 
the individual routines. 

When RBM reads the [UTILITY command, it loads the Program 
Control routine (root segment) from the RAD and transfers 
control to the Program Executive which controls the operation 
of the Utility program. The Executive first scans the 
[UTILITY control commond parameters. If the nome pa- 
rameter is omitted, the Executive assumes that the control 
commands that follow use the Control Function Processor 
only. If a specific Utility routine is referenced with the 
name parameter, the Program Executive checks the name 
for validity. If the name is invalid, the message 



** UT NT RES 



(Utility not resident) is written on OC and DO and the 
Utility program aborts. If the name is valid, the overlay 
segment containing the Utility routine is loaded from the 
RAD, flags ore initialized, and control is transferred to the 
named routine. 

When the Progrom Control rout ine encounters on lEOD cord 
image from SI, it terminates processing. The form of the 
I EOD command is 

XJEOD 



This causes the Utility program to transfer control back to 
RBM. 



The Sequence Editor always reads from SI, whether or not 
a KP key-In is In effect. 
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If a Utility routine encounters the control command !UT [name] 
[,parameter], normal termination occurs and the named rou- 
tine is loaded and given control without return to RBM. 

CONTROL COMMAND FORMAT 

All Utility program control commands are input from SI and 
are listed on the LL device as they are interpreted. The 
general format is 

!*mnemonic specification 



where 

! identifies the record as a control command, 

* indicates that the control command is unique to 

the Utility program, 

mnemonic is the code name of a Utility command 

and begins immediately following the !* characters, 

specification is a series of parameters unique to 

the specific command. The conventions used in 
specifying parameters are (1) a string of up to five 
decimal digits having a value less than 32,768 
denotes a decimal integer and (2) a string con- 
taining more than five characters is always assumed 
to be EBCDIC, regardless of content. 

One or more blanks separate the mnemonic and specifica- 
tion fields, but no blanks may be embedded within a field, 
A control command is terminated by the first blank after the 
specification field; or, if the specification field is absent 
and a comment follows the mnemonic field, the command is 
terminated by a period. No control command record may 
contain more than 80 characters. The first two characters 
of the mnemonic portion of the command are sufficient to 
define a control command; the remaining characters may 
be omitted, since they are ignored when present, 

CONTROL FUNCTION COMMANDS 

The Control Function Processor interprets and executes con- 
trol commands that are common to all Utility subroutines. 
These control function commands are given below. Unless 
otherwise noted, "opib" is the operational label of the de- 
vice, "number" is the number of file marks or records to 
skip (if omitted; the number is assumed to be 1), and "de- 
vice" is the device type and physical device number. 

FBACK The l*FBACK command backspaces a magnetic 

tape over a specified number of file marks or a sequential - 
access RAD file to beginning-of-tape (BOT), The form of 
the command is 

!*FBACKoplb[, number] 



The |*FBACK command cannot be used for random files. 



FSKIP The !*FSKIP command spaces a magnetic tape 

forward over a specified number of file marks or a sequential- 
access RAD file over its end-of-file. The form of the com- 
mand is 

I *FS KIP oplb[, number] 



The !*FSKIP command cannot be used for random files. 

MESSAGE The !*MESSAGE command writes messages 

to the operator on the OC and the DO devices. The form 
of the command is 

I *MESSAGE message 



where message is any EBCDIC character string up to a full 
card image. 

The format of the output is 

!*MESSAGE message 

PAUSE The I *PAUSE command causes a message to be 

written on the OC and DO device followed by a wait for 
the operator's response. The form of the command is 

I* PA USE message 



where message is any EBCDIC character string up to a full 
card image. 

The format of the output is 

l*PAUSE message 
HBEGIN WAIT 



PRESTORE The l*PRESTORE command causes all control 

commands to be read from the SI device, but not to be in- 
terpreted or executed until an lEOD is read. The prestored 
commands are written on a temporary RAD file (using opera- 
tional label X5) and are read sequentially from the RAD. 
(The prestore mode is set automatically when a name param- 
eter appears on the I UTILITY command and one or more 
operational labels have been assigned to the same device 
or RAD DFN as SI. ) The !*PRESTORE control command 
must immediately follow the {UTILITY control command 
and must precede any other control commands for the Util- 
ity program. The form of the command is 

! *PRESTORE 
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REWIND The !*REWIND command causes the specified 

magnetic tape or sequential -access RAD file to be rewound. 
The form of the command is 

!*REWINDoplb 



WEOF The I *WEOF command writes a file mark, EOD, 

or end-of-fi le pointer if appropriate to the device. The 
form of the command is 

!*WEOF opib 



RBACK The !*RBACK command backspaces a magnetic 

tape or sequential -access RAD file over a specified number 
of records. The form of the command is 

l*RBACKoplb[,number] 



If opIb is assigned to a blocked sequential -access RAD file, 
the number parameter is the number of logical records to be 
skipped. The 1*RBACK command cannot be used for random 
files or compressed RAD files. 



RSKIP The !*RSKIP command spaces forward the indi- 

cated magnetic tape or sequential -access RAD file over the 
specified number of records. The form of the command is 

l*RSKIPoplb[,number] 



If opib is assigned to a blocked sequential -access RAD file, 
the number parameter is the number of logical records to 
skip. The !*RSKIP command cannot be used for random 
files but can be used for compressed RAD files. 



UNLOAD The !*UNLOAD command unloads a magnetic 

tape or closes a sequential -access RAD file. The form of 
the command is 

!*UNLOAD opIb 



END The !*END command is treated exactly tike an 

lEOD; that is, transfers control from Utility to the Moni- 
tor, This command should be used in place of !EOD when- 
ever multiactivity job stacks are to be prestored on a RAD 
file. This command will not be interpreted as an EOF when 
read from UI. The form of the command is 



^END 



ASSIGN The I*ASSIGN command allows a Utility user 

to assign any operational label to any other background 
operational label, device-file number, or RAD file. The 
form of the command is 



!*ASSIGN 



oplbl } 



opIb 

dfn 

f i le,area 

fdun 



where 

dfn is a device-file number. 

file is a RAD file name. 

area is the RAD area within which the RAD file is 

defined. 

fdun is a FORTRAN device unit number. 



COPY ROUTINE 

COPY provides the ability to copy variable-length binary 
or EBCDIC records from cards, paper tope, magnetic tape, 
keyboard/printer, and sequential -access RAD files to cards, 
paper tape, magnetic tape, line printer, keyboard/printer, 
and sequential-access RAD files. Using control functions 
of the Control Function Processor, records and files can 
be skipped except for random files. The COPY routine 
also provides for file verification (separate from the copy 
operation). If the binary mode is requested for either copy- 
ing or verifying, file marks are recognized for paper tape, 
magnetic tape or sequential RAD file. An !EOD card is 
recognized as a file mark. The number of records and files 
read or verified is listed upon completion of the COPY or 
VERIFY operation. 

Since COPY uses RBM routines M:READ and M:WRITE for 
all reading and writing, files copied with the COPY routine 
will be treated according to the default conventions of the 
FORM, size, and BIN parameters of the !*COPY command. 
Deviation from inherent conventions is accomplished via 
FORM, size, and BIN parameter options. 



For records being copied to the card punch, records con- 
taining a first byte of X' IC, X'3C', X'9F', X'BF', X'DF', 
X'FF', X'OO', or X'78' are always punched in the binary 
mode; all other records are punched in EBCDIC. For all 
other devices, the distinction between binary and EBCDIC 
modes is meaningless because records are copied directly 
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without translation. Therefore, attempting to copy binary 
data to an EBCDIC device will result in meaningless output. 



For paper tape, if BIN and size are not specified, the 
length of each binary record (first byte of X'lC, X'3C', 
X'9F', X'BF', X'DF', X'FF', X'OO', or X'78') is always 
120 bytes. When M:READ reads EBCDIC records from paper 
tape, it transmits only the number of bytes specified by the 
calling sequence to memory. Ordinarily, the COPY rou- 
tine assumes that paper tape EBCDIC records have a byte 
count of 120. The size specification allows the user to 
override the standard count. 



By assigning the X4 opib to a RAD file or paper tape device 
before the !*OPLBS command is read, records copied from 
UI are adjusted to a 80- or 120-byte length, depending upon 
the contents of the first byte. 



When copying or verifying a 9-track magnetic tape to a 
7-track magnetic tape, UI and X4 should be assigned to 
the 9-track device. 



If a record copied to the line printer or keyboard/printer 
contains more than 132 characters, only the first 132 are 
printed. Normally, the first character of the record is 
printed and single spacing is forced. Therefore, even if 
the first character is intended for format control, it will be 
printed as the first character of the print line in the normal 
mode. If the format option is specified, the first character 
is interpreted as a format control character and is not 
printed. 



The BIN option should be used to copy nonstandard binary 
records. Paper tape codes NL, EOM, and / are not inter- 
preted as editing characters. All records are copies on a 
byte-for-byte basis. If paper tape is the input source, 
leading blanks are ignored and trailing blanks are included 
in the byte count. Paper tape !EOD NLis recognized as 
a file mark if it occupies the first five bytes of a record. 



COPY OPERATIONAL LABELS 



COPY OPERATING CHARACTERISTICS 

The COPY routine checks whether input/output operational 
labels are assigned to the same physical device or same disk 
file as control input. If so, all control commands are read 
from the SI device and stored in memory prior to interpre- 
tation of the control commands to begin copying. When the 
SI and any input or output operational labels are assigned 
to the same physical device and attend mode is In effect, 
the message 



** LD INPUT UI,ddnn 
HBEGIN WAIT 



is written on the OC and DO device. The operator should 
load the input at this point and enter an S key-In to initiate 
the actual copy procedure. 

If the operational labels are not assigned to the same physi- 
cal devices, interpretation of control commands takes place 
as they are read from SI, and copying begins Immediately 
without any message being output on the OC device. 



CALLING COPY 

The COPY routine is requested with the control command 



!UTILITYCOPY[,CORE] 



where CORE specifies that, for the first !*COPYor !*VERIFY 
command, the records from the input device are stored in 
core in addition to being copied or verified. For subsequent 
!*COPYor ! *VERIFY commands, these records in core, 
rather than those on the input device, are used as the input 
source. Following any !*COPYor !*VERIFY commands, 
record and file counts are displayed on the DO device. 



After interpretation of the [UTILITY control command, con- 
trol is transferred to the COPY routine which interprets the 
control commands listed below. 



The following operational labels are used by the COPY 
routine in addition to the Utility subsystem operational 
labels: 



Label 



Usage 



UI 


Copy input. 


X4 


Verify input. 


UO 


Default copy output or second verify Input 



Other operational labels may be used by COPY (at the op- 
tion of the user) to specify a second input device for veri- 
fying or an output device for copying. 



COPY CONTROL COMMANDS 

OPLBS The !*OPLBS command identifies the operational 

labels of output devices to be used in COPY requests and 
input for comparison for VERIFY requests. The input for 
COPY operations is read from UI. For VERIFY operations, 
X4 is read. Operational labels may be assigned to any de- 
vice. The form of the command is 



!*OPLBSoplb^,...,oplb 



COPY Routine 115 



where opibj (I < 8) is the operational label or fdun for an 
output device for subsequent I *COPY commands, or for an 
input device for subsequent !*VERIFY control commands. 
UI or X4, may not be specified. In the absence of an 
!*OPLBS command, the default is UO. (SI prestore mode 
is determined after each !*OPLBS command.) 



COPY The !*COPY command causes records from the 

input device (UI) to be copied on the output device (speci- 
fied in the !*OPLBS command) until the requested number 
of lEODs or file marks has been reod and copied, or until 
the specified number of records has been copied. The form 
of the commartd is 



! *COPY type [, number] [, FORM][, size] 



I 



BIN 
ETA 
ATE 



in 



^here 



type is R if the number parameter refers to records, 

or F if the number parameter refers to fi les. 

number has different meanings, depending upon 

the type parameter that precedes it. If the type 
parameter is R, "number" is the number of records 
to be copied, but refers to logical records for a 
blocked, sequential-access file. If "type" is F, 
"number" is the number of files to be copied, or 
is ALL, indicating that all files should be copied 
until two consecutive EOD images or file marks 
are copied. If "type" is F and any of the input/ 
output devices is a sequential -access RAD file, 
"number" is 1 or it is omitted. If the number pa- 
rameter is omitted, one record or file is copied. 

FORM applies only if data is being copied onto 

the line printer or keyboard/printer. If the FORM 
parameter is omitted, single spacing of printed 
output is the format. If FORM is used, the first 
character of each record is used for format control 
and is not printed. 



ETA specifies that the data read from the input 
operational label is to be converted from EBCDIC 
to ASCII before copying out to the devices speci- 
fied on the l*OPLBS control command. Refer to 
Appendix E for the EBCDIC— 'ASCII translation 
table. 

ATE specifies that the data read from the input 

operational label is to be converted from ASCII 
to EBCDIC before copying to the devices speci- 
fied on the I*OPLBS control command. Refer to 
Appendix E for the EBCDIC -—* ASCII trarwiation 
table. 

P specifies thot a page eject is to be performed on 
all !*OPLB line printer devices prior to and after 
execution of the current command. 



BCOPY The ! *BCOPY commarKi causes records from 

a user blocked disk file or magnetic tape to be copied on 
the output device (specified on the l*OPLBS command) until 
the requested number of records or a complete file has been 
copied. This command allows for the case where the lost 
record written is a short record by setting the SR flag on 
the write operation (see MrWRITE). The form of the com- 
mand is: 

/[ *BCOPY type[, number] , , size [J^^"^}] 



where type, number size, ETA, and ATE ore defined as 
for the !*COPY command. Size must be specified equal 
to or greater than the actual record size to prevent loss of 
data. 



VERIFY The !*VERIFY command requests comparison of 

data on the X4 device with data in core (CORE option) or 
with data from devices specified in the !*OPLBS control 
command. The form of the command is 



!*VERIFY type[, number] [, size] 



m 



size specifies the maximum number of bytes in each 

record. If data is being copied to or from a 
sequential-access RAD file, "size" is the maximum 
logical record size and must be an even number. 
If "size" is omitted, all records are read and written 
in the standard record size (]20 bytes). An !EOD 
card will not be recognized by M:WRITE if an odd 
byte count is specified or if a byte count of less 
than four bytes is specified. 

BIN if omitted, mode (BIN or EBCDIC) is deter- 

mined according to byte I of the record. If pres- 
ent, all copying is done in binary, either with 
the count specified in "size" or the standard rec- 
ord size (120 bytes) by default. 



The parameters ore defined as for the l*COPY control 
command. 

Before the !*VERIFY control command is issued, itisassumed 
that all files have been repositioned, if necessary, by use 
of l*REWIND and other file positioning control commands 
(described in "Control Function Commands"). The entire 
verification process is completed when the number of files 
or records for verification has been compared. 



DUMP ROUTINE 

The DUMP routine is used to dump records or files onto an 
output device in either hexadecimal or EBCDIC format. 
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DUMP uses M:READ and M:WRITE for all input/output. If 
no mode Is specified for dumping, all records are dumped 
according to the contents of the first byte of each record. 
Any record having a first byte of X'lC, X'3C', X'9F', 
X'BF', X'DF', X'FF", X'OO', or X'78' is assumed to be a 
binary record containing 120 bytes, and is dumped with 
each data word being represented in EBCDIC as a 4-digit 
hexadecimal number. Any record that does not contain one 
of these characters in its first byte is assumed to be in 
EBCDIC and is dumped as such. 

The user has the option to specify the byte count for paper 
tape record input, since M:READ pads all EBCDIC records 
with trailing blanks so that they appear to be fixed length 
in memory. 



CALLING DUMP 

The DUMP routine is requested with the control command 
! UTILITY DUMP[,oplb] 



where opib is the operational label or device input number 
of the input device. If the opIb is omitted or empty, the 
operational label is set to UI, 



DUMP CONTROL COMMAND 



The HEX option for dumping should be used to dump non- 
standard binary records. The option causes all records that 
are to be dumped to be read in binary and dumped with each 
data word represented in EBCDIC as a four-character hexa- 
decimal number. Since no editing is done when a binary 
read is specified, NL, EOM, and «i are not interpreted as 
editing characters. !EOD is recognized as a file mark. 



DUMP The ! *DUMP command causes records to be read 

from UI and written on the LO device in the specified mode 
until an lEOD or file mark Is read, or the specified number 
of records has been read. The form of the command is 

l*DUMP [number] [,mode][,size] 



^here 



DUMP OPERATIONAL LABELS 

The DUMP routine uses the following operational labels: 

Label Explanation 

LO Output device for dumping. 

UI Input device for dumping, unless some other 

input device is specified. 

DUMP OPERATING CHARACTERISTICS 

If both SI and DUMP input are assigned to the same device, 
all of the control commands on the SI device are read and 
stored in memory before interpretation of the commands and 
dumping of the input tape begins. When this occurs, the 
message 



** LD INPUT UI,ddnn 
HBEGIN WAIT 



is written on the OC and DO device. The operator mounts 
the input tape and enters an S key-in to continue. 



If SI and the tape device to be dumped are not assigned to 
the same device, no message is written and control com- 
mands are interpreted as they are read. The DUMP control 
commands are then listed on LL and dumping is performed. 



number is a decimal integer. Only the specified 

number of records is dumped. If "number" is omit- 
ted, the file is dumped to an EOF or file mark. If 
"number" is ALL, the dump is performed to double 
file marks or lEODs. 

mode indicates that all records on UI, regardless 

of the content of the first byte of each record, are 
written on the LO device in the mode specified. 
"Mode" is HEX for hexadecimal and EBCDIC for 
EBCDIC. If omitted, the record first byte sets mode. 

size specifies the maximum number of bytes to be 

read in each record. If the dump "input" is a 
sequential -access RAD file, the size parameter 
must be an even number. For a blocked sequential- 
access file, "size" is the maximum logical record 
size. If it is omitted, the standard record size is 
used. 



OBJECT MODULE EDITOR ROUTINE 

The Object Module Editor is designed to maintain files con- 
taining sets of Xerox Standard Object Language modules. 
It generates or updates files by inserting and deleting object 
modules according to the program name in the start module 
item for each module. For each output file written, a list 
of module names is printed in the order of their appearance. 

Object Module Editor is also used to list files containing 
object modules and to verify that the input object records 
contain no checksum or sequence errors. 
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A binary object module is defined as a sequence of binary 
records in Standard Binary format, each of which begins 
with a nonblank name item and terminates with a record 
whose first byte is X'9F' (END card) indicating that the 
record contains an end item. 



A set consists of one or more object modules and is termi- 
nated by a file mark or !EOD. A tape may contain one or 
more sets and is terminated by double file marks or lEODs. 
Only one set of object modules can be contained in a 
sequential -access RAD file. 



Note that the Object Module Editor routine does not main- 
tain the object modules in the System library and User 
Library areas on the RAD. These permanent areas are main- 
tai ned via the RAD Editor {see Chapter 8). 



OBJECT MODUU EOlTOfi OPERAHOIIAL tABElS 

The Object Module Editor uses the following operatiorral 
labels: 



Label Explanation 

BI Device-file from which binary object 

modules are to be inserted* 

LO Device-file for listing either UI or UO 

object module names. 

UI Input device -file. 

UO Output device-file. 



OBJECT MODULE EDITOR OPERATING CHARACIERISTiCS 

Object Module Editor operates in two modes: list and 
modify. 

In the list mode, only UI is read. The names of the object 
modules are printed on LO, arjd the checksum and sequence 
for each record are verified. After interpreting the ! *LIST 
control command, the Editor checks if any two of SI , BI, 
and UI are assigned to the same device or disk file. If so, 
the message 



** LD LIST UI,ddnn 
!! BEGIN WAIT 



is written on OC. The operator responds by preparing UI 
and entering an S key-in. Listing of the modules proceeds. 

If no two of the labels 51 , BI, or UI are assigned to the 
same device, control commands are interpreted as they are 
read and are written on DO. If the UI device is assigned 
to a sequential -access RAD file, the Object Module Editor 
leaves the list mode after reading the er>d-of-file. 



In the modify mode, any modules to be inserted are read 
from the 61 device and written on UO, as indicated by the 
control commands. If there are input files to be updated, 
they are read from -UI. The names of all object modules 
written on UO are listed on LO. The object modules on 
BI must be in tbe same order in which they are to be in- 
serted on UO, or BI must be rewound before each INSERT 
command. If BI is a disk file it is rewound with each 
INSERT command. 

The Object Module Editor operates in the "prestore" mode 
(reading and storing commands before interpreting) when 
ffie conditions shown below «ccur; otherwise, the Editor 
operates dynamically. 



Qjerational Labels* Assigned 
to Same Device-File 



Prestored Data 



SI, BI SI 

SI, UI SI 

BI, UI BI 

SI, BI, UI SI, BI 

61 is never prestored if assigned to d disk file. 

After entering the modify mode, the Object Module Editor 
operates as follows; 

If any two of the operational labels SI , 81, and UI are as- 
signed to the same device-file. Object Module Editor fol- 
lows the steps below: 



1. 



Interpretation of control commands begins. If any ob- 
ject modules are to be inserted, and if SI and BI are 
assigned to the same device, the SI device is read until 
an lEOD is encountered and the message 



** LD INSERTS UI,ddnn 
!! BEG IN WAIT 



is written on OC and DO. The operator loads the mod- 
ules to be inserted on the BI device and keys in an S. 
If SI and BI are assigned to different devices or files, 
no message is written. The Editor then reads in all the 
modules on BI until either an lEOD or any other record 
with a first byte different from X'FF' or X'9F' is read 
from BI. Blank records are ignored. 

2. If there are input files to be updated, the message 



** LD INPUT UI,ddnn 
! 'BEGIN WAIT 



is written on OC and DO. The operator must prepare 
UI and enter an S key-in. 



The mode modification control commands are inter- 
preted, causing updating or generation to proceed. Each 
control command is listed on LL as it is interpreted. 



Substitute OC for SI if a KP key-in is in effect. 
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If no two of the operational labels SI , BI, and UI are 
assigned to the same device-file, control commands from SI 
are read and interpreted dynamically. Records are read 
from BI and UI and written on DO in response to each mode 
modification control command. Every control command is 
listed on LL. 

Object Module Editor uses M:READ and M:WRITE to perform 
all input/output. Each object module is identified by the 
program name stored in the start module item. No modules 
with blank names are even written on the DO tope. 



CALUNG OBJECT MODULE EDITOR 

The Object Module Editor is requested with the control 
command 



A 



UTILITY OMEDIT 



After interpretation of the lUTILITY control command, 
control is transferred to the Object Module Editor routine. 
The control command and options available to OMEDIT are 
described below. 



Object Module Editor begins reading control commands 
until an !EOD or an !*END is read, which terminates 
the input. 



OBJECT MODULE EDITOR CONTROL COMMANDS 

LIST The |*LIST command causes the Editor to enter the 

list mode. The names of the object modules on UI are read 
and listed on LO. Any checksum errors detected cause 
error messages to be written on LO, but listing continues. 
If the record is an !EOD, it is listed. If two consecutive 
lEODs are encountered, the Editor leaves the list mode and 
the next control command is interpreted. The form of the 
command is 



A 



!*LIST 



MODIFY The !*MODIFY command indicates that ob- 

ject modules av& to be output on the UO device and causes 
the Editor to enter the modify mode. The modify mode ter- 
minates when an !EOD command is interpreted from SI. 
The form of the command is 



!*MODIFY 



[TGEN |1 
LllNSERTjJ 



where 



GEN is an optional parameter indicating that ob- 

ject modules are to be selectively input from BI 
and that files are to be generated on UO, UI is 
not read. The control command !*MODIFYGEN 
may be followed only by !*INSERT control com- 
mands (GEN Implies !*INSERT) used to define the 
elements to be selectively copied from BI to UO, 
No !*DELETE control commands may be used in 
the GEN mode, 

INSERT must be specified if insertions from BI are 

to be read. If BI and UI are assigned to the same 
non-disk device, the complete BI file (up to an 
!EOD) will be prestored. Modules can be selected 
from BI by names on the !*INSERT control com- 
mands. The inserts must be in proper order. This 
command is used to update (input both !*INSERT 
and !*DELETE commands) UI and to write UO, 



Note: If INSERT and GEN are omitted from the ! *MODIFY 
control command, only !*DELETE control commands 
may be input. 



Substitute OC for SI if a KP key-in is in effect. 



MODIFY SYSTEM RBM SYSGEN magnetic tapes or any 

object module file can be rapidly and easily updated by use 
of l*MODIFY SYSTEM, a UTILITY OMEDIT control com- 
mand. This command updates UI to UO with new object 
modules inserted from BI. Deletion and insertion are done 
in the sequence; read BI for IDENT, record back BI, delete 
UI object module with IDENT corresponding to that just read 
from BI, and insert new object module from BI. This process 
continues until the specified number of files are updated and 
written to UO. BI is rewound with this command. UI may 
contain mixed EBCDIC (80 byte) and standard RBM binary 
(120 byte) records. 

Note: The first six records of the RBM SYSGEN system 
are nonstandard binary records and are copied 
automatically. 

The form of the UTILITY OMEDIT control command is: 
/\ *MODIFY SYSTEM, n 



Any number of files (n) may be copied to UO from UI with 
binary object modules inserted from BI modules replacing 
those containing the same IDENT from UI. All BI object 
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modules are inserted until an EOF is encountered. UI is 
copied to UO until n files (default = 31)are written to UO. 
An additional EOF Is then written to UO and return Is to 
RBMJCP. No l*END or !EOD control commond is required. 
(Note that !*END control command will cause a monitor 
CC abort. ) BI must be assigned to a RAD or magnetic tape 
file with an EOF terminating the object modules. Object 
modules from BI must be in the order that they are encoun- 
tered on UI. Appropriate error messages followed by aUT 
background abort results when errors are detected. 



INSERT The ! *INSERT command causes an object mod- 

ule to be inserted and Is effective only in the modify mode. 
The form of the command is 



l*INSERT name [,rK3me_] 



where 



nameij is the name (up to eight EBCDIC characters) 

of the object module to be inserted. 

nameo Is the name (up to eight EBCDIC characters) 
of the object module on UI thot the namej object 
module must follow. If nameo is omitted, the 
namei module Is written following the module 
previously written on UO. 



RECORD EDITOR ROUTINE 

The Record Editor is used for source editing by record 
number from any sequential device to any other sequential 
device. Record Editor provides the following capabilities: 

1. Generates files containing source data. 

2. Lists files containing source images In addition to asso- 
ciated line numbers. 

3. Lists selected records in a file. 

4. Modifies files containing source images. 



RECORD EDITOR OPERATIONAL LADELS 

The following operational labels must be assigned in addi 
tion to the standard Utility program operational labels: 

Label Explanation 

SI Input device for control commands. 

LO Output device for listing source images. 

UI Input device. 

UO Output device. 

Note; Substitute OC for SI if KP key-in is in effect. 



RECORD EDITOR 0PERAT1II6 CHARACTERISTICS 



Modules to be inserted from BI must be In the same order as 
In the INSERT control commands. If GEN Is specified on 
the MODIFY command, only the name] parameter In the 
INSERT command Is required; if a name2 Is specified. It Is 
Ignored. If BI is a disk file, it Is rewound with each IN- 
SERT command. 



The Record Editor routine operates in two modes: list and 
modify. 

In the list mode, the Editor reads source images from UI and 
lists them on the LO device. It associates each image with 
a decimal line number, starting with 1. 



DELETE The DELETE command causes object modulesto 

be deleted and Is effective only In the modify mode. The 
form of the command is 



I* 



DELETE name [,name ] 



where 

nome-i is the program name (up to eight EBCDIC 

characters) of the first or only module on UI to be 
deleted. 

nome2 is the program name (up to eight EBCDIC 
characters) of the lost module on UI to be deleted. 
If absent, only one module is deleted. 

The ! *DELETE control command must name modules in the 
same order as their occurrence on UI. 



In the modify mode, the Editor either updates or generates 
files on the UO device. 

Record Editor uses MrREAD and MrWRITE to perform all 
input/output. Therefore, all the paper tape editing and 
keyboard/printer editing that Is standard to these routines 
Is performed. 



CALLING RECORD EDITOR 

The Record Editor Is requested with the following control 
command 



lUTILITYRECEDIT 



After Interpretation of the ! UTILITY control command, con- 
trol is transferred to Record Editor, which begins reading 
control commands. 
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RECORD EDITOR CONTROL COMMANDS 

A command requesting either the list or modify mode must 
immediately follow the ! UTILITY command. All other con- 
trol commands are interpreted as subcommands under each 
mode. 



If a binary record is read from UI, Utility aborts after issu- 
ing the following message on OC and DO: 



** MODE ERR UI, device 



LIST The !*LIST command (list mode) causes the previous 

mode to terminate. The source files are read from UI and 
listed on LO. Each EBCDIC source image is listed along 
with an associated line number up to and including the 
first !EOD source image or file mark read. After the 
required number of files has been listed, another control 
command is read. Each ! *LIST control command, file 
mark, or !EOD causes the line numbering to restart with 1, 
The form of the command is 

l*LIST [number] 



where number indicates the number of files to list. Listing con- 
tinues until two consecutive lEODs are encountered or the 
specifiednumberof files is listed. If "number" is omitted, one 
file is listed. If number is zero, the from/to parameters form 
limit pairs that define inclusively the records to be listed from 
the current file. Limit pairs must be in ascending order, 
except that two equal pairs causeonlyone record to be listed, 

A !*AAODIFY, !*END, or lEOD control command causes 
the list mode to terminate. 

MODIFY The !*MODIFY command informs the Record 

Editor that files are to be either generated or updated. It 
terminates the previous mode and initiates the modify mode. 
The form of the command is 



!*MODIFY [LIST] [, GEN] 



/here 



LIST indicates that a listing of records deleted or 

inserted will be produced on LO. If LIST is the 
only parameter used, the listing will contain the 
UI line numbers (the number deleted or the num- 
ber preceding the one inserted). If GEN is also 
present, the UO line numbers will be listed. 

GEN indicates that records are to be read from SI 

(there is no input on UI) and written on UO. If 
updating is to be performed (that is, there is input 
to be read from UI), the parameter field is left empty. 



The modify mode is terminated whenever a ! *LIST, 
l*MODIFY, !*END, or !EOD control command is input 
from SI. When the modify mode is terminated and GEN is 
specified, an !EOD or file mark is written on UO. When 
the modify mode is terminated and GEN is not specified, 
the remaining source images of the file on UI (until an EOD 
is encountered) are written on UO, followed by an EOD or 
file mark. 

DELETE The !*DELETE command causes the indicated 
record source images to be deleted and is effective only in 
the modify mode. The form of the command is 



I* 



DELETE number [, number-] 



where 



number] is the line number of the first (or only) 

source image to be deleted. 

number2 is the line number of the last source image 

to be deleted. 



INSERT The l*INSERT command causes record source 

images from SI to be added to UI and written onto UO, and 
is effective only in the modify mode. The form of the com- 
mand is 

!*INSERT number 



where number is the line number that the insertions are to 
follow. If a line number of (zero) is used, the insertions 
will precede the first line. 

Every source image on SI following the !*INSERT control 
command is inserted until a new Record Editor control com- 
mand is encountered. 

CHANGE The !*CHANGE command causes the indicated 

source images to be deleted, and the source images fol- 
lowing the CHANGE command to be written on UO. The 
command is effective only in the modify mode. The form 
of the command is 



|*CHANGE number [, number-] 



where 

number] is the line number of the first source image 

to be deleted. 

number2 is the line number of the last source image 

to be deleted. If omitted, only one source image 
will be deleted. 

Following the !*CHANGE control command, every source 
image on SI is inserted until another Record Editor control 
command is encountered. 
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SEQUENCE EDITOR ROUTINE 



SEQUENCE EDITOR OPERATING CHARACTERISTICS 



The Sequence Editor edits EBCDIC card images by sequence 
number. It is more flexible than the Record Editor in that 
multiple programs or sections of programs may be updated 
and sequenced individually within single or multiple files. 
It provides greater protection from updating in an incorrect 
sequence, or from accidentally updating the wrong program. 
Another feature of the Sequence Editor routine is that update 
card images may be inserted without changing the existing 
sequence numbers. Thus, update decks may be cumulative 
and will reflect the development of a source program. 

The Sequence Editor is primarily intended for installations 
where EBCDIC source programs are kept on magnetic tape. 
It is somewhat impractical for paper-tape-oriented systems 
or systems without a line printer. 

Editing is accomplished by designating columns 73 through 80 
of a source card image as the "sequence field". This field 
consists of two parts, the ident and the sequence number. 

The optional ident is that portion of the sequence field that 
uniquely identifies a program or program segment. If de- 
fined, the ident begins in column 73 of the card image and 
is from one to six alphanumeric characters in length. 

The required sequence nunfber is that portion of the sequence 
field that is sequenced numerically. It consists of from two 
through eight decimal characters and ends in column 80 of 
the card image. The user can specify the value by which 
successive sequence numbers are incremented. In general, 
a large sequence increment will allow larger insertions 
without affecting the existing sequence numbers. 

Together, the ident and sequence number must not total 
more than eight characters. Any unused columns will be 
between the ident and the sequence number and will be 
ignored by the Sequence Editor. 



SEQUENCE EDITOR OPERATIONAL LABELS 

The following operational labels are used by the Sequence 
Editor routine: 

Label Explanation 

SI Updatedata (includes card images and con- 

trol commands). Not effected by K P key- in . 

LO Annotated listing of added and deleted 

card images. 

UI Input device. 

UO Output device. 

Device, above, refers to any permanent storage device such 
as magnetic tape, paper tape, or RAD (single sequential 
f i le). Note that LO should not be assigned to the keyboard/ 
printer, because the sequence number portion of the print- 
out is truncated on that device. 



The Sequence Editor performs two separate and distinct 
functions: generates files on UO from source images input 
on UI and updates files from UI onto UO, taking updates 
from SI. Only one of these functions can be performed per 
call to the Sequence Editor (SEQEDIT). 

The file generation (GEN) function is used to create the 
permanent files initially. It is required that files be se- 
quenced as they are generated. The user can generate one 
file (terminated by a file mark) wherein a single file mark 
is written on UO, or multiple files (terminated by two file 
marks) wherein two file marks are written onto UO and UO 
is backspaced one file. 

The update function is used to update U I by replacing, delet- 
ing, or inserting card images from SI and writing the updated 
files onto UO- The files can be resequenced as they are 
written. The user can update one file (terminated by on EOF 
from UI) wherein an EOF is written onto UO, or all files 
(terminated by logical end-of-tape or two EOFs from UI) 
wherein two file marks are written on UO and UO is back- 
spaced one file. With the ALL option, it is not necessary to 
update each file, but all files will be copied onto UO. 

Sequencing is a separate operation in that the card images 
are sequenced as they are written on UO. Thus, it is possible 
to update an existing file by ident and sequence number while 
placing a new ident and sequence number on the update file. 



CALLING SEQUENCE EDITOR 

The Sequence Editor is requested via the control command 
/! UTILITY SEQEDIT, [GEN][,IGN][,ALL] 



where 

GEN indicates that output files are being gener- 

ated on the UO device and that there are no input 
files to be updated. 

IGN in update mode indicates that UI sequence 

errors are to be ignored if UI is being updated. If 
IGN is used, no sequence error messages are 
printed. 

In GENmode, IGN indicates thatUO isnot listed. 

ALL indicates that the function is to continue until 
two EOFs are encountered from UI. 

The leading comma must be specified. 

The Program Executive transfers control to the Sequence 
Editor, which interprets and validates the parameters. If 
illegal parameters are input, the Utility program aborts with 
a code of UT. If this is an update (the GEN option was not 
specified), the following message is output on OC and DO. 



** LD INPUT UI,ddnn 

! 'BEGIN WAIT (if attend mode only) 
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SEQUENCE EDITOR GENERATE CONTROL COMMAND 

SEQUENCE The !*SEQUENCE command is used to 

sequence columns 73 through 80 of the card Images on DO. 
Only one file can be sequenced with each !*SEQUENCE 
command. The form of the command is 

!*SEQUENCE sequence field, increment 



/here 



sequence field contains the sequence number of the 

first sequenced card image to be written on the 
output tape, 

increment is the sequencing increment number. If 

omitted, an increment of 10 is used. It is the re- 
sponsibility of the user to ensure that the sequence 
number does not get incremented past the size of 
the sequence number field. No warning is issued 
if this overlap occurs. 



SEQUENCE EDITOR UPDATE CONTROL COMMANDS 

IDENT The !*IDENT command defines the breakdown 

of the sequence field into the ident and the sequence num- 
ber. It applies to card images from UI and SI only. If used, 
it should precede the update cords to which it applies. If 
omitted, the ident field is considered empty and the se- 
quence number is eight characters in length. The I*IDENT 
control command is used whenever it is necessary for the 
Sequence Editor to know the size and content of the ident 
field (that is, when UI contains multiprogram files or single- 
program files with nondecimal characters in the sequence 
field). It is not to be used when files are being generated. 
The form of the command is 



1*IDENT [ident][, sequence-number] 



^here 



ident is on integer n] (0 < n^ < 6) that specifies 
the number of characters in the ident subset of the 
sequence field starting from column 73, If "ident" 
is omitted, the ident field does not exist. 



sequence-number is an integer n2 (2 < n2 ^ 8) that 

specifies the number of characters in the sequence 
number subset of the sequence field ending in 
column 80. If omitted, sequence number is set 
equal to the difference (8 - ident). 



The user should note that if a nonzero ident field has been 
specified on an !*IDENT command, the idents on each card 
image from UI must match exactly or resequencing will be 
suspended when the first nonmatching ident is encountered. 
Hence, if UI is known to have nonmatching idents (for ex- 
ample, a file that has never been sequenced or one that has 
been updated and contains some blank sequence fields), a 
separate sequence operation should be performed (without 
a simultaneous update) specifying an empty ident field. 

Replacement. The update card itself, rather than a control 
command, is used to replace a card image from UI. The 
sequence number on the update card must equal the sequence 
number on the UI cord image to be replaced. The card im- 
age for UI and the message "DELETED", followed by the 
card image from SI and the message "INSERTED" are output 
on LO. 

Insert. The update card itself, rather than a control 
command, is used to insert a card image on UO. The se- 
quence number on the update card must be between the 
sequence number of the two continuous UI card images 
where the update card is to be inserted. The card image 
from SI and the message "INSERTED" are output on LO. 
Cards without sequence numbers are inserted immediately 
following the sequenced card preceding them. Thus, a 
large block of card images can be inserted by placing the 
proper sequence number on the first card only. The nonse- 
quenced cards will be written on the output tape without 
sequence numbers. It is recommended that the tape be re- 
sequenced as it is being updated if unsequenced cards are 
inserted. 

DELETE The !*DELETE command deletes one or more 
card images from UI. Nonsequenced cards can only be de- 
leted by deleting from the last sequenced card preceding 
the nonsequenced card(s) up to and including the next se- 
quenced card. Deleted card images are listed on LO. The 
form of the command is 



73 



80 



!*DELETE [sequence fields] 



sequence field. 



sequence fields indicates that the images are to be 

deleted from the ident and/or sequence number in 
sequence field^ up to and including the ident and/ 
or sequence number in sequence field2. 

sequence field i contains the ident and/or sequence 

number of the first or only card image to be de- 
leted from UI. This parameter is required. 

SUPPRESS The !*SUPPRESS command is identical to the 
!*DELETE control command except that no deletion and 
images ore listed on LO. The form of the command 



/'. 



73 
-H— 



80 
-+- 



!*SUPPRESS [sequence fields] 



sequence field ^ 
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SEQUENCE The !*SEQUENCE command is used to 

resequence columns 73 through 80 of the card images on 
UO. Only one program can be resequenced with each 
!*SEQUENCE command. Therefore, resequencing is sus- 
pended when either a file mark or a card image with a 
sequence number identifying a new program is written on 
the output tape. Resequencing is also suspended when 
another l*SEQUENCE command is executed; therefore, 
parts of a program as well as entire programs can be rese- 
quenced. The form of the command is 



73 



80 



> H H 

X {^SEQUENCE seq. fields , increment seq.field. 



sequence field2 contains the ident and/or sequence 

number of the first resequenced card image to be 
written on the output tape and does not neces- 
sarily have the same fields as defined in the 
l*IDENT command. (The !*IDENT command 
defines sequence fields for the input tape and 
update data only.) If omitted, resequencing is 
suspended. 

increment is the resequencing increment number. 

If omitted, an increment of 10 is used. It is the 



responsibility of the user to ensure that the 
sequence number does not get incremented past the 
size of the sequence number field. No warning 
is issued if this overlap occurs. 

sequence fie Id ^ contains the ident and/or sequence 

number from Ulatwhich the !*SEQUENCE command 
becomes effective. If omitted, the !*SEQUENCE 
next card image to be written on UO. 



UTILITY ERROR MESSAGES 

Table D-5 of Appendix D lists the error messages issued by 
the Utility Subsystem. Unless otherwise noted, the follow- 
ing definitions apply in these messages: 

Code Explanation 

opib Operational label of the device. 

device Device type or physical device number. 

The operator response to a 1 1 BEGIN WAIT message on OC 
may be any valid, appropriate, RBM unsolicited key-in, 
such as S to continue processing, or X to abort fob. Other 
appropriate key-in may precede an S key-in if desired. 
The I JBEGIN WAIT message is used only if attend mode 
is in effect. 
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10. PREPARING THE PROGRAM DECK 



The following examples show some of the ways program 
decks may be prepared for RBM operation. Unless stated 
otherwise, standard default cases for device assignments 
are assumed, 

EXTENDED SYMBOL EXAMPLES 

ASSEMBLE SOURCE PROGRAM, LISTING OUTPUT 
AND BINARY OUTPUT 



In this example, the source decks are assembled in batch 
mode (BA). In this mode, successive assemblies may be 
performed with a single IXSYMBOL command until a 
double !EOD command is encountered. The parameters 
defined on the IXSYMBOL command will hold true for 
each assembly in the batch. Each assembly will be fol- 
lowed by a Symbol cross-reference (CR). 



z: 



IFIN 



!EOD 



Source deck 



^ 



IXSYMBOL BO, LO 



UOB 



In this example, the symbolic input is received from the 
SI device (always defaulted), the binary output is received 
on the BO device, and the listed output is received on the 
LO device. Note that although BO and LO are normally 
default cases, they must be specified if output to the GO 
file (also a default) is not desired. 

ASSEMBLE IN BATCH MODE, LISTING OUTPUT AND 
BINARY OUTPUT WITH SYMBOL CROSS-REFERENCE 



X 



I EOD 



!EOD 



Source deck n 



=^ 



I EOD (optional) 



Source deck 2 



z 




y 



EOD (optional) 



Source deck 1 




IXSYMBOL BA,LO,BO,CR 



IJOB 



ASSEMBLE, LOAD, AND GO FROM USER DEFINED 
OV FILE. LISTING OUTPUT 



IXEQ 



lEOD 



!$ROOT ,,GO 



lOLOAD 



! ASSIGN OV=USEROV,UP 



Z 



I EOD 



Source deck 



<> 



IXSYMBOL LO, GO 



UOB 



Z 



I EOD 



!#ADD UP, USEROV,4 



! RAD ED IT 



{PAUSE KEYIN SY, S 



! ATTEND 



IJOB 



In this example, the user is defining his own OV file 
through a call to the RAD Editor. After assembly, the OV 
file is assigned to the user defined file. The call to the 
Overlay Loader (lOLOAD) causes it to load the module 
defined on the !$ROOT command to the USEROV file for 
execution. The advantage to assigning the program to a 
user-defined OV file rather than using the RBMOV file is 
that the program can be loaded into core for execution 
repeatedly without reassembly. Conversely, the contents 
of RBMOV cannot be guaranteed to be saved from one job 
to another. 
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ASSEMBLE SOURCE PROCRAM. 
LISHNG OUTPUT. LOAD AMD 60 



[rXEQ 



lEOD 
[fSROOT ,,GO 



lOLGAD 



ZI 



I !EOD 



^ 



Source deck 



leek X/ 



JXSYMBOL LO,GO 



UOB 



In this example, the binary object module is loaded into 
the RBMGO file located in the System Data area. The call 
to the Overlay Loader (lOLOAD) causes it to load the mod- 
ule defined on the !$ROPT command to the RBMOV file for 
execution. The double comma on the !$ROOT command 
informs the Loader that the temp, exFoc parameter options 
are defaulted. 



BASIC FORTRAN IV EXAMPLES 



COMPILE MULTIPLE PROGRAMS 



Z. 



!FIN 



!EOD 



Source Deck(s) 



{FORTRAN XP 






!EOD 



Source Deck(s) 



{FORTRAN LO,XP 



I {ASSIGN GO=0 



'JOB 




In this example, output to the GO file is not desired in the 
first job, so the GO opib must be assigned to (see Appen- 
dix E and {ASSIGN command writeup irt Chapter 2). An 
object listing is desired (LO) and exteruied precision real 
data is specified. 

The second job will receive a source listing by default and 
extended precision real data is again specified. Since the 
parameters are different on the two {FORTRAN control 
commands, the jobs cannot be run in batch mode. 



COMPILE, USTING OUTPUT, LOAD AND GO 



Z 



IFIN 



lEOD 



Data deck 



!XEQ 



I {EOD 



1 




{$ROOT ,,GO 
4 l$ML 



{OLOAD 



{EOD 



Z 



1 



deck 



O 



{ FORTRAN 



{ATTEND 



{JOB 



In this example, the {ATTEND command specifies that 
the Monitor is to go into a "wait" state instead of 
aborting the job in case of irrecoverable error (gener- 
ally recommended for "load and go" jobs). Binary out- 
put will be received on both the BO and GO devices 
by default, and standard precision mode is also assumed 
by default. The binary object module is loaded into 
the RBMGO file located in the System Data area. 

The call to Overlay Loader (JOLOAD) causes it to 
load the module defined on the I$ROOT command to 
the RBMOV file for execution. The double comma on 
the l$ROOT command informs the Loader that the temp, 
exioc parameter options are defaulted. The Loader is 



126 Basic FORTRAN IV Examples 



requested to output a LONG mop (!$ML). The !XEQ 
command causes the executable program to process the 
data deck. 



SEGMENTED PROGRAM EXAMPLES 

ASSEMBLE SEGMENTED BACKGROUND PROGRAM, 
LOAD AND GO 



COMPILE AND EXECUTE FOREGROUND PROGRAM 

This example would be used for debugging purposes only. 



Root (seg 0) 



seg 1 



seg 2 



seg 3 



!XEQ 



!EOD 



!$ROOT ,+1800, GO 



!$TCB +DB0D,+1200 



lOLOAD ,F 



! PAUSE KEYIN FG,S 



!EOD 



FORTRAN source statements 



^ 



! FORTRAN 



lASSIGN BO=0 



UOB 



In this example, binary output to the BO device is 
suppressed. The {FORTRAN control command specifies 
that the binary output is to be received on the GO file 
by default and standard precision mode is assumed. The 
I PAUSE command permits the operator to key in FG, S 
to access protected foreground memory. The program is 
defined to the Overlay Loader as a foreground program 
(!OLOAD,F) and the COMMON base is set to the 
FWA of the background. The Loader is to create the 
Task Control Block, the first two words of which are 
defined on the !$TCB command. These two words spe- 
cify that the task is to be connected to interrupt loca- 
tion X'lOD' (Intergral interrupt number 2, priority level 8, 
within group 0). 



The l$ROOT command specifies that the root is to be 
loaded from the GO file, and will start execution at 
location 1800 in foreground memory. The core image 
form of the program is loaded on the OV file (RBMOV). 
The IXEQ command loads the executable program into 
core. When loaded, the task is armed, enabled, and 
then triggered. 




Given the program tree structure shown above, the sample 
deck setup illustrates a background program with a root and 
three overlay segments. These are assembled and loaded 
into the RBMGO file. The lOLOAD command specifies 
that these three segments are to be loaded, and defines it 
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as a backgrounci program (B). The $SEG commands specify 
that segments 1 through 3 are attached to the root, and the 
modules are to be Eooded from the RBMGO fUe to the 
RBMOVfile for subsequent loading into core for execution. 
A load map is output (i$MP). 



LOAD AND EXECUTE MULTIPLE OBJECT MODUUS 



Given the sample program tree structure shown above, the 
Illustrated deck would load ond execute the segmented 
program. The program Is loaded from either the device or 
file ossigned to the BI operational label. No load map is 
requested (an !$ML, l$MS, or !$MP command could be 
inserted after the lOLOAD command If a map was desired). 
Although the segments could be looded in any order, the 
proper calling sequence is the responsibility of the user. 





seg I 




seg 4 


1 




seg 5 


^ 


,Root 


seg2 


f 


1 




1 




seg 3 


— f 





yz 



!XEQ 
I !$END 



1 Ob feet module 




!$SEG3,0,BI, 1 



y 



X 



2 Obfect modules 



!$SEG 2,0,BI,2 



1 Object module 



$SEG5,1,BI,1 



/zz 



V 



1 Object module 



$SEG 4,],BIJ 



1 Object module 



l$SEG 1,0,BI, 1 



zz 



3 Binary object modules 

■\ [$r6ot ,,BI,3 



»OLOAD5,B 



IJOB 



J/ 



RAD EDITOR EXAMPLES 



BUILD PUBLIC UBRARY 



!EOD 



Relocatoble birrary module 5 



^ 



6 



LJ. 



Rfelocatable binary module 2 



Relocatoble binary module 1 



[$PUBLIB E,BI,5 
I lOLOAD 



.'ASSIGN OV=PUBLIB, UP 



lEOD 




^ i'^ADD UP, PUBLIB, 48, 0, R, R 



I^ADD SD, LIBSYM, 20, 0, R, R 



IRADEDIT 



! PAUSE KEYIN SY, S 



UOB 



The Public Library is core resident. In this example, the 
user must create two RAD files to set up the Public Library: 
the LIBSYM file and the PUBLIB file. The LIBSYM file 
contains the Symbol Table for the Public Library and is used 
by the Overlay Loader to satisfy references to the Public 
Library. The PUBLIB file contains the Public Library and 
is booted in with RBM. (RBM must be rebooted to load the 
updated Public Library.) 
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LOAD ROUTINES IN USER LIBRARY 



z 



!#END 



Object module (RMAX ident) 




i.^LADD UL,RMAX,B 



Object module (TUU ident) 




!#LADD UL,TUU,E 



z: 



Object module (RDATA Ident) 



^ 



!#LADD UL, RDATA, M 



!#ADD UL,MODULE,150J20,P,R 



!#ADD UL,MDFRF,2,0,R,R 



i.^ADD UL,BDFRF,2,0,R,R 



1/ 



!#ADD UL,EDFRF,2,0,R,R 



l#ADD UL,EBCDIC,6,0,R,R 



!#ADD UL,MODIR,3,0,R,R 



IRADEDIT 



I PAUSE KEYIN SY, S 



!JOB 



In this example, the User Library requires the following 
six files to be allocated in the User Library area (UL): 
MODIR, EBCDIC, EDFRF, BDFRF, MDFRF, and MODULE. 
The I^LADD command enters the routines into the defined 
four files, depending on the library code parameter on the 
I'^LADD command: Basic (B), Main (M), or Extended (E). 
The same basic method is used to set up the System Library, 



UTILITY EXAMPLE 

CREATE A CONTROL COMMAND FILE 

1 !EOD 



Z 



IJOB 



Control command deck 



iJOBCt 



::i 



0\ 



!*END 



!*COPYF 



!*OPLBS UO 



!*ASSIGN UO=CCFILE,UD 



!*ASSIGN UI=SI 



[UTILITY COPY 



I'^END 

ji^ADDUD, CCFILE,5,80,C,N 



IRADEDIT 



IJOB 



In this example, the job stream will create the compressed 
file CCFILE in the User Data area. Control commands will 
be read from the SI device into file CCFILE. The job 
stream on CCFILE may now be executed by assigning 
CC = CCFILE, UD. Note that CCFILE must not have a 
IJOB command on Its first entry, since this would imme- 
diately transfer CC back to the SYSGEN assignment. How- 
ever, it is often convenient to end the control command 
file with a IJOB command to initiate a return to the 
SYSGEN assignment. 



A ! JOB command must not be the first card in the control 
command deck; UOBC is permissible. 
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11. SYSTEM STARTUP 



The startup of an established RBM system (that is, subsequent 
to system-generation time) is normally performed either by 
"booting" from a self-loading 'system-save tape', or by 
booting directly from the system disk if the latter has not 
been disturbed (e.g., used for another purpose) since the 
previous shutdown of the system. As part of this startup 
process, updating of the public library and the resident 
foreground can be achieved, as well as absolute system 
patching applied to both core and RAD images. 

Other forms of initial system loading and system updating 
are described in the RBM/SM Reference AAanual, 90 30 36. 



SYSTEM SAVE TAPE 

A system save tape is produced by assigning operational 
label BO to magnetic tape and using the ^SAVE function of 
the RAD Editor, omitting the FILE parameter, while the 
System is in an operational state (e.g., prior to shutting 
down). All RAD and/or disk pack areas necessary to sub- 
sequent system operation should be specified to be saved. 
The tape will contain a first block bootstrap routine, a 
restore program, and the saved disk areas. After the restor- 
ation of the system disk image, the restore program auto- 
matical ly initiates an RBM boot from the system disk device. 

The restore program issues the following message: 





RESTORING VERSION xx OF mm/dd/yy 


hrmn 


As 


each area is restored, the 


message 








RESTORING area TO dn 


(dn = 


device 


number) 



and attempt to read the original tape device number. The 
restore operation will continue when the next reel is 
mounted and the tape drive is placed in the automatic mode 
(by pressing START on the tape drive control panel). 

Table 20 lists the error messages that may be output while 
restoring the system to the RAD/disk. 



Table 20. Save-Tape Restore Error Messages 



is issued, unless DATA switch 2 is up. If the area is the 
first area being restored to a disk pack or cartridge disk, 
the message 



Message 


Restore Program Action 


Operator 
Action 


WRITE PRO RAD 


Keep trying to perform 
write operation. 


Reset RAD 
write- 
protect 
switches. 


SEQ ERR 


Keep trying to read 
the tape successfully. 


Restart or 
abort^ . 


CHECK WRITE 
ERR 


Keep trying to per- 
form write/check- 
write operation. 


Restart or 
abort^. 


CHSM ERR 


Keep trying to read 
the tape successfully. 


Restart or 
abo^t^ 


TAPE TRANS. 
ERROR 


Keep trying to read 
the tape successfully. 


Restart or 
abort^ 


RAD TRANS. 
ERROR 


Keep trying to per- 
form write operation. 


Restart or 
abort . 


To restart, rewind tape and reboot; to abort, activate 
PCP interrupt which causes loading of the current area 
to be abandoned. Following the abort, the tape is 
searched for the next area to be restored. 



IDLE, RUN TO WRITE 



is issued. If it is permissible to write on the indicated de- 
vice, the operator must move the COMPUTE switch to IDLE 
and back to RUN in order to continue. 

If an end-of-tape condition is sensed, the restore program 
will rewind the tape off-line (i .e., set it to the manual 
mode), output the message 



MOUNT NEXT REEL 



RAD or disk pack. 



RBM BOOT PROCEDURE 

The RBM boot procedure is essentially the same whether the 
system is loaded directly from the system disk or from a self- 
loading save tape (of the form described above) via the disk. 
The principal difference is that in the former case a standard 
hardware- load operation is initiated from the system-disk 
device; in the latter case, from the tape drive on which the 
save tape is mounted (the subsequent load from disk is auto- 
matic). In either case the actual boot process is effected 
by the loading to memory and execution of the RBM boot- 
strap record. 

The RBM bootstrap will initially move itself to high core and 
then read in RBM from the system processor area of the RAD. 
The information necessary to read in RBM is contained in 
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the bootstrap and is supplied at system generation time 
when the bootstrap is written on the RAD. After the resi- 
dent portion of RBM is loaded, control is transferred to an- 
other bootstrap that loads the remainder of the RAD. This 
second bootstrap functions in the overlay region of the RBM. 

The second bootstrap initially inputs the Transfer Vector 
Table to complete the loading of the resident portion of 
RBM. Next, if DATA switch 4 is not set, an attempt is 
made to assign an operational label to the PUBLIB file in 
the user processor area. If a Public Library is present, the 
assignment will be made and the bootstrap then inputs the 
Public Library. If DATA switch 4 is set, the Public Library 
will not be loaded. After the Public Library is processed, 
a Hex Corrector patching routine (see below) will be acti- 
vated if DATA switch 1 is set. If DATA switch 3 is not set, 
the bootstrap then searches the SP, UP, and FP area direc- 
tories (in that order) for all files flagged as a resident fore- 
ground file. All such files are loaded one at a time as they 
are encountered in the file directory and their initialization 
routine is executed if one exists. The initialization routine 
can do any required housekeeping (such as repositioning all 
appropriate files), arm and enable the appropriate interrupts, 
and then return control to bootstrap. (The initialization 
routine is linked by an RCPYI P, L instruction.) It expects 
to have control returned to the address in the L register. 
Hence, the bootstrap will read in the resident foreground 
programs one by one and execute any initialization routine 
unless DATA switch 3 is set. 

The system is then completely loaded and the bootstrap sets 
the protection registers, outputs the following messages (if 
DATA switch 2 is not set), and enters a wait state: 

1 1 AFTER 'WAIT' SET PROTECT 

I ISET PARITY 

!! KEY-IN 'S' TO BEGIN 

If the computer enters a "wait" state before the above mes- 
sages are output, the bootstrap was not successful in loading 
the required data. This would usually be caused either by 
a parity error while reading the RAD or by a faulty fore- 
ground program. 

Note that if the above messages are inhibited by setting 
DATA switch 2 prior to execution of the boot, the opera- 
tions indicated by the messages should still be performed, 
however, in order to ensure system integrity. 



PUBLIC LIBRARY CREATION OR UPDATING 

The Public Library can be created and thereafter can be 
completely regenerated any time the user desires. A file 
with the name PUBLIB will have to be defined via the RAD 
Editor in the User Processor area for the Public Library, and 
a file named LIBSYM must be defined in the System Data 
area of the RAD. The relocatable binary decks of all rou- 
tines to be specified as being in the Public Library are 
loaded by the Overlay Loader (via the !$PUBLIB control 
command) and an absolute core image version is written by 
the Overlay Loader on the RAD file defined as PUBLIB. 



Before executing the Overlay Loader, the operator must 
key in SY so that the Loader can write in a protected RAD 
file. 

When a Public Library is successfully loaded, additional up- 
dating of RAD files will be done by the Overlay Loader. 
The Public Library Transfer Vector Table will be input from 
the RAD and either created (for an initial load) or updated 
for succeeding loads. This process consists of linking each 
Public Library definition (DEF) in the Symbol Table to a 
transfer vector and linking the transfer vector to the value 
of the DEF. When the linkage is completed, the Overlay 
Loader writes the new Public Library Symbol Table into a 
previously defined file (called LIBSYM) in the system data 
area of RAD. For an initial load, this file will be previ- 
ously defined, via the RAD Editor, with the name LIBSYM. 
The new Transfer Vector Table is then written on the RAD 
(replacing the previous one), and the Loader exits to 
M:TERM. (Note that RBM must be rebooted from the RAD 
in order to load the Public Library into core memory.) The 
Public Library should not be loaded into core (by rebooting 
the system from the RAD) until the user has reloaded all 
foreground and background routines that use the Public 
Library. 



RESIDENT FOREGROUND CREATION OR UPDATING 

Resident foreground program files must be defined via the 
RAD Editor. These files may be in the System Processor (SP), 
User Processor (UP), or Foreground Program (FP) area of the 
RAD. Also, the parameter (RF) on the l^ADD command 
specifying that this is a resident foreground file will have 
to be set. One RAD file can be defined for each fore- 
ground program, thus allowing an update to be done on a 
program basis as opposed to the entire resident foreground 
area. The Overlay Loader reads in a relocatable binary 
deck of each foreground program and creates an absolute 
core image version of the program in its predefined RAD 
file. Foreground programs assembled as absolute sections 
must be loaded with an ABS control command. Prior to ex- 
ecuting the Overlay Loader, the user may key in SY to 
specify that the protected RAD files can be written on. 

For an update, only those programs being modified need be 
reloaded. However, if a program exceeds its allocated core 
space, other programs must be reloaded and relocated at a 
new absolute address in a different area of core. 

The Overlay Loader (or the Absolute Loader) will store in 
the first sector of each file the appropriate header informa- 
tion that the RBM bootstrap needs to load and initialize each 
foreground program. The information needed by the boot- 
strap consists of the following items: 

1 . Load address . 

2. Number of bytes in program. 

3. Entry address of initialization routine (if present). 

If no initialization routine is specified, the RBM bootstrap 
will initialize the task's interrupt level from information in 
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ihe TCB. The task may also be triggered at this point if 
the TCB so specifies. 

After a resident foreground program is created on the RAD 
and is ftagged for automatic boot-time loading in its file- 
directory entry, it is brought into core by manually reboot- 
ing the system from the RAD. It can also be brought into 
memory by inputting a {processor or IXEQ commartd with 
oplobet OV assigned to its RAD file. 



All patch decks are terminated by an EOD control command. 
To patch relative to the start of program modules, a bias 
card may be used. Its form is 



bbbb 
ID 



i:^ 



wher 



bbbb is the bias (load origin of the program) and 

the following correctors are loaded relative to 
that location. 



SYSTEM PATCHING 

Patches to the Monitor or Public Library may be loaded at 
boot time if DATA switch 1 is set. Monitor patches will 
also be written to the RAD, thus ensuring a permanent 
change to all future boots. All patch cards have the form 



aaaa,cccc Tcccc ,cccc ][*comments] 



wh< 



aaao is the first (or only) absolute core memory lo- 

cation to be modified. 

ccccj are the desired (hexadecimal) contents of 

aaaa and the following n-1 locations. 



Patches may also be loaded dynamically to user program 
(or the Monitor) in either of two ways. 

1. Following a HEX control command. 



2. Following an unconditional H key- in. 



PA means that the following patches are to be 

loaded relative to the RBM Patch Area. 

XX is an RBM overlay ID; thus the corrections fol- 

lowing the bias card are loaded relative to the 
overlay base. 

Note: All patches at boot time to the monitor or a monitor 
overlay will be written to the RAD. At other times, 
three cells of the RBM Patch Area are needed for 
each overlay patch. The overlay length is also ex- 
panded to the next sector boundary (or maximum of 
512 words) to allow use of the end of the overlay as 
a dynamic patch area. 

Any value on a patch card preceded by an R (Recce j) will 
have the current bias added to it. Any value on a patch 
card preceded by a P(Pcccc{) will have the bias of the RBM 
Patch Area added to it. Any value on a patch card preceded 
by an O (Occcc;) will have the bias of the RBM overlay area 
added to it. Any value on a patch card preceded by a 
J (Jcccc|) will have the bias of the JCP added to It. 

The programmer must not modify the first and last cells of 
the Patch Area, as the first contains the length of the Patch 
Area and the last contains the number of temporary RBM 
overlay patches. As mentioned previously, three words of 
the Patch Area are needed for each overlay patch, taken 
from the top of the Patch Area downward. When an RBM 
overlay is read into core, the Patch Area is searched for 
patches for that overlay. If any are found, they are ap- 
plied before control is passed to the overlay. 
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12. DEBUG 



INTRODUCTION 

This chapter describes the use of Debug and its interface 
with RBM. 



GENERAL DESCRIPTION 

The RBM Debug package is a debugging tool primarily de- 
signed for nonoverlaid background programs, with limited 
facility for foreground programs. It provides the user with 
the following capabilities: 

1. To transfer control to the control device from a speci- 
fied location in the user's program or through the Con- 
trol Panel Interrupt. 

2. To dump selected core and registers on the keyboard/ 
printer or the line printer. 

3. To modify memory locations and registers. 

4. To logically insert code at specified memory locations. 

5. To begin or continue execution at a specified memory 
location (i.e. , selective execution). 

6. To perform conditional memory dumps (snapshots) of 
registers and selected core locations at a specified 
location and optionally transfer control to the con- 
trol device. 

7. To step through a program. 

FOREGROUND USER'S DEBUG CAPABILITY 

Debug can be used to aid the checkout of a foreground pro- 
gram operating at priority levels lower than the Control 
Panel Interrupt level. To accomplish this. Debug is moved 
to the Control Panel Interrupt level, where it may be di- 
rectly entered by pressing the Control Panel Interrupt switch. 
The Control Task remains at the lowest interrupt level. 
Key-ins requesting Control Task functions may be mode by 
typing a "slash" (/) followed by NEW LINE (@) in re- 
sponse to the DKEYIN message. Snapshots may be placed 
in all tasks whose interrupt level is lower than the Control 
Panel Task. 

OVERLAY USER RESTRICTIONS 



When a snapshot is inserted in a currently resident seg- 
ment using d Debug control command, the snapshot Is 
valid only until the segment is overlaid, since Debug 
operates only at execution time on resident programs. 
This problem is reduced by allowing the user to assem- 
ble Debug calls into his program. 



RBM AND FOREGROUND USER'S INTERFACE 

Debug is normally a subtask of the RBM Control Task with 
a priority just below the IDLE subtask. Debug is triggered 
by any of the three resident Monitor routines (D:SNAP, 
D:KEY, or D:CARD), by the KEYIN subtask, or by the Job 
Control Processor (JCP). JCP triggers Debug when it re- 
ceives an XED command, and the system loader transfers 
control via D:KEY. When a foreground user wishes to use 
Debug, he gives control to Debug by an !XED card or by 
an unsolicited key-in of DE. After Debug has control, the 
foreground user moves Debug to the Control Panel Task level 
with a Define command. After debugging, the foreground 
user issues the Debug command Q which restores Debug to 
its original level. 



MEMORY REQUIREMENT AND INSERTION 
BLOCK DEFINITION 

The executive portion of Debug is a foreground program that 
may be resident or nonresident. If the program is resident, 
it must be so specified when the Debug file is created with 
the RAD Editor. It is read into core when RBM is booted. 
If the program is nonresident, it is loaded like any other 
foreground program (see Chapter 6), Debug has the follow- 
ing core memory requirements: 



1. Executive 

2. Zero table 

3. Overlays 

4. Insertion block 



440 locations 
35 locations 
RBM overlay space 
User-defined 



The insertion block is an area of core that stores user- 
inserted code, and the zero table cells are used to refer- 
ence these insertions (see Appendix C). 



DEBUG CONTROL 

Control can be given to Debug in the following ways: 

1. A direct call to Debug. 

2. The execution of a snapshot. 

3. An unsolicited key-in of DE. 

4. The Debug execution card (IXED). 

5. Control Panel Interrupt (see Foreground Capability, 
above) . 

A direct call on Debug is a user-coded request for Debug to 
read a command. The call has the form 

RCPYI P,A 

B D:KEY or D:CARD 
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When the entry Is D:KEY, Debug prints the message 



M.DKEYIN 



A Debug command will then be redd from the proper device- 
file number assigned at SYSGEN. 

Note that after the initial direct call on Debug a foreground 
task will have to exit in order to move Debug to a higher 
interrupt. 

D:KEY, DrCARD, D:SNAP (snapshot) are small reentrant 
routines that actual I /trigger Debug. An unsolicited key-in 
during Debug will not harm the user's environment. The 
IXED command performs the same function as the !XEQ 
command except that Debug is called via D:KEY before 
executing the user's program. 



DEBUG COMMANDS 

After Debug has control, it interprets the following 
commands: 



Code Function 

D Define 

I Logically insert code 

S Insert snapshot 

X Step (move) snapshot 

R Remove snapshot or insertion 

T Perform selective dump on keyboard/ 

printer and Debug output device 

P Perform selective dump on Debug output 

device 

C Set Debug input device to the card reader 

K Set Debug input device to the keyboard/ 

printer 

M Modify memory 

B Branch (i.e., return control to program) 

E Exit from interrupt level 

Q Terminate Debug 

G Global symbol table pointer 

Debug uses MrREAD and MrWRITE for input/output; and 
hence the keyboard character NEW LINE terminates a line, 
EOM deletes a line, and cent (/) deletes the previous 
character. Debug interprets the semicolon character (;) 
(if not in the message field of a snapshot) as a continua- 
tion character. The semicolon will terminate the line (or 
card and continue the command to the next line (or card). 
Blanks are ignored except within the message field of a 
snapshot. 



Most Debug commands specify registers and memory loca- 
tions. Registers are specified as follows: 

RP Program address register 

RL Link address register 

RT Temporary register 

RB Base address register 

RX Index register 

RE Extended accumulator 

RA Accumulator 

RR Al I of the above 

Locations are specified in one of the following forms: 

1. One to four hexadecimal digits. 

2. SNAME, where NAME is an IDNT and its value is the 
load origin of such module. The Overlay Loader D 
option must be invoked if the user is to use IDNT names 
with Debug. 

3. Sums or differences of values of either of the above two 
forms. 

Examples: 

A14 
SSQRT 

ABC+$SUB1+1492 
SSUBl - SSUB2 

If the SNAME option is invoked, the user must define an in- 
sertion block (see the Debug Define command, below), and 
the last K:BLOCK words of the insertion block are used as 
a buffer for the IDNT names. 

D (Define) 

The Define command is used to define an Insertion block 
when the Debug commands S or I or the SNAME option Is to 
be used. 

The form of the Define command is 

y : 

D [start ,end][,CP] 



where 



start is the memory location of the first cell of the 

insertion block. 

end is the memory location of the last cell of the 

insertion block. 

CP Is an optional request to move Debug to the 

Control Panel Interrupt level. The default level 
is the RBM Control Task level. An unsolicited 
key- in of FG must be In effect when the level is 
specified. 
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I 



(Insert) 



The Insert command designates the insertion of one or more 
instructions logically before (IB), after (lA), or replacing 
(IR) the instruction at the designated location (loc). 

The form of the Insert command is 



A 
R 



loc,inst, , . . . ,inst 
I r 



IB designates Insert Before 

lA designates Insert After 

IR designates Insert Replace 

The instructions may be designated In one of the following 
forms: 

1. op* loc 

where op isa two-digit hexadecimal value representing 
the operation code and address modification. The sec- 
ond digit (i. e. , address modification) must be one of 
the following: 

designating direct addressing 

2 designating indexing 

4 designating indirect addressing 

6 designating indirect addressing and indexing 

This instruction form relieves the user of creating the 
actual address structure for Sigma 2/3. It does not apply 
to the conditional branch instruction (operation code 
6) nor to the register copy instructions (operation 
code 7). Debug will actually expand an instruction 
designated in this form into more than one instruction; 
for example, 82*1492 will expand into 



8E02 


LDA 


*$+2, 1 


4802 


B 


$+2 


1492 


DATA 


X'1492 



See "Debug Expansion of Instructions", later in this 
chapter, for a description of the expansions. 



2. 6x*loc 



where x designates the desired conditional branch; 
for example, 6E*1492 designates a BAN 1492 and will 
expand into 



6E02 


BAN 


$+2 


4803 


B 


$+3 


4C01 


B 


*$+l 


1492 


DATA 


X'1492 



See "Debug Expansion of Instructions", later in this 
chapter, for a description of the expansions. 



3. hex value 

which is inserted with no expansion, 

4. Any mnemonic copy instruction in the Sigma 2 and 
Sigma 3 Computer Reference Manuals. The comma 
between the register specifications must be omitted. 

The results of an insertion are defined in "Debug Expansion 
of Instructions", later in this chapter. 

An example of the insert command is as follows: 

IBSSUB+IOOO, 80*SSUB+25, 75A1, 40*SSQRT+0,; 
RCPYIPL,ROR*LT,REOR XB 

S (insert Snapshot) 

The Insert Snapshot command inserts (in the same manner as 
the instruction Insert Before) a snapshot at the designated 
location so that when control passes through loc, the fol- 
lowing transpires prior to executing the instruction that was 
at loc: 

1, The optional conditions are evaluated, and if false, 
the snapshot is bypassed. 

2, If the conditions ore true (or if none are specified), the 
following Is output: 

SNAP AT loc 

message (if any) 

followed by the designated dumps. 

Such output is always transmitted to the Debug output de- 
vice; and if any of the dumps designate the keyboard/ 
printer, then the SNAP and the message line also will be 
transmitted to the keyboard/printer. A user can make a 
maximum of 32 snapshot and instruction insertions (see "De- 
bug Insertion Structure", later in this chapter, for the call- 
ing sequence for a Snapshot command.) The form of the 
Insert Snapshot command is 



locL/conditions/]['message'] [,dump requests] 



S is a request to snapshot and resume execution. 

SK is a request to snapshot and transfer control to 

the keyboard/printer for Debug input. 

SS is the same as SK, but may be stepped (see 

Debug command X). 



conditions 
message 
dump requests 



are as described below. 
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Condif-ionis. The format of the conditions is 



llf} ^2{f} '3"- {]] 'n 



/here r. is a relational expression of the form 



toe 
constant 

register 



H 



= 


'loc 


< 




> 
< = 


constant 


> = 




<> 


register 



where constant is the some form as a loc preceded by a "^; 
for example, 

#1492 or #$SUB+57 

The meaning of the operations in hierarchical order are 
as follows: 

equal 

< less than 

> greater than 

< = less than or equal to 

> = greater than or equal to 

< > not equal 

& logical and 

I logical or 

The comparison is arithmetic unless the operator is preceded 
by an asterisk (*), In which cose the comparison Is logical. 

Message. Message is a string of any EBCDIC characters ex- 
cept quote ('). 

Dump Requests. The format of the dump requests (if any) Is 
.. [T]. 



[T] 



register 
loc 
loc . . , 



register 

loc 

loc . . . loc 



where T designates a particular dump to be output on both 
the keyboard/printer and the Debug output device. If T Is 
absent, the dump will be output to the Debug output device 
only. Only one dot (. ) is necessary in specifying a block 
of memory locations. Extra dots ore Ignored. 

An example of the snapshot command Is as follows: 

S$SUB+505/RA=# 0&]492<1496/'TAB1 FULL', 
$TAB1...STAB1+256, RR 

X (Step Snapshot) 

If control Is at the Debug Input device as a result of a 
stepping snapshot (SS), the X command moves the snapshot 



to memory location n, keeping the same conditions, mes- 
sage, and dump requests. Control is then transferred to the 
branch location. 

The form of the Step Snapshot command is 

/X [^n[,branch]] 



where 

n is the memory location. 

branch is the branch location. 

If the snapshot was executed at location ALPHA, the de- 
fault cases are branch -^ ALPHA and n ALPHA+1. 

R (Remove Snapshot or Insertion) 

The Remove command restores the displaced instruction to its 
original memory location. The command releases the zero table 
entry and. If the entry Is the latest snap or insertion, re- 
leases its space in the Insertion block. Note that the space 
In the insertion block Is regained only if the Remove com- 
mand affected the latest entry In the insertion block. 

The form of the Remove command Is 



/R loc, , Ioc„, . . ., loc 



where loc Is the memory location. 

T (Selective Dump on the Keyboard/Printer and the 

Debug Output Device) 

The T command outputs the contents of the requested loca- 
tions and registers In hexadecimal on both the keyboard/ 
printer and the Debug output device. Console Interrupt 
will transfer control to the keyboard/printer after the cur- 
rent line Is output. 

The form of the T command is 



r 



T dumps 



where dumps (i.e., dump requests) have the following forms 
(there can be several dump requests In any order separated 
by commas): 



loc 


SSUB+3 




loc ... loc 


$SUB . . 


3FFF 


register 


RA 




all registers 


RR 
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(Selective Dumps on the Debug Output Device) 



Examples of the M command are 



This command is identical to the T command except that the 
dumps go only to the Debug output device. 

The form of the P command is 



(' 



P dumps 



C (Debug Input Device) 

The C command gives control to the Debug input device. 

The form of the C command is 



K (Keyboard/Printer) 

The K command gives control to the keyboard/printer. 

The form of the K command is 



v^ M (Modify Memory) 

The M command modifies memory locations or registers. 
The form of this command may be either of the following: 
M register,word 



M l|_Mloc,word , . . . ,word 



loc is the first memory location to modify. 

wordj is the hexadecimal value (or mnemonic reg- 

ister operation; see item 4 under the Debug I 
command) to be stored in the designated register 
or at location loc+i. 



P if present, is a request to print the hexadecimal 

value of the effective location, its previous value, 
and its nev/ value. 

T if present, is a request to type the hexadecimal 

value of the effective location, its previous value, 
and its new value. 



1. M$SUB+1, 4, 1, $SUB+2, RADDIZE 

where the following cells are modified if SUB is lo- 
cated at 100, 



Loc 


lO 

Value 


0101 


0004 


0102 


0001 


0103 


0102 


0104 


7C68 


MRA, $SUB 





This sets the A register to 0100. Note that an MRP 
command will change the program address portion of 
the program status doubleword. 

3. MT149A, RCPYIPA 

This will produce the following output if the contents 
of location 149A was FFFF prior to the command 
149A: FFFF— 75F1. 

B (Branch) 

The Branch command allows the user to insert loc into the 
program address portion of the program status doubleword 
and to exit from Debug. If loc is not present, the user just 
exits from Debug. 

The form of the Branch command is 



/B [loc] 



E (Exit From Interrupt Level) 

The E command allows the user to force an unusual exit from 
the highest active interrupt level below Debug. Debug will 
still have control after this command. 

The form of the E command is 



(' 



(Quit Debug) 



The Q command causes Debug to reset its internal flags and 
zero table ceils, restore RBM's original interrupt level, 
trigger the Job Control Processor, and exit. If the X option 
is present. Debug will also disconnect (i.e. , unload) itself 
from the system. 

The form of the Q command is 
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G (Global Symbol Table Pointer) 

The G command specifies the first location of a symbol table 
separately created at assembly time, or by the use of modify 
(M) commands. The symbols may be used in any of the com- 
mands in place of a location or a value by preceding the 
symbol with an @ sign. The symbol is assigned its corres- 
ponding value as part of command processing. The symbol 
table is composed of a set of five-word entries for each 
symbol, followed by one word set equol to zero. Each sym- 
bol must be left- justified and padded with blanks for a total 
of eight characters. The value of the symbol is placed in 
the fifth word. 

The form of the G command is 



/g start 



DEBUG EXPANSION OF INSTRUCTIONS 

EXPANSION OF INSERTED INSTRUCTIONS 

Class 1 instructions that are inserted via the insert (I) com- 
mand are expanded into more than one instruction if desig- 
nated in the op *address form. (Note that expansions of 
indirect instructions are not reentrant. ) 



Op is direct (0): 

op 

B 

DATA 



*$ + 2 

$+2 

address 



Op is indexed (2): 



where start is the location of a symbol table. 



op 

B 

DATA 



*$ + 2, 1 

$+2 

address 



Op is indirect (4): 



DEBUG ERROR MESSAGES 

Error messages ore shown below: 



Message 

ERROR SYNTAX 
ERROR COMMAND 
ERROR FOREGRND 



ERROR OVERFLOW 



ERROR IN/OUT 



Meaning 

Syntax error 

Command error 

Command attempts to affect 
foreground without a hard- 
ware interrupt level specified 
for Debug (see Debug D 
command) 

Either insertion block or zero 
table overflow 



Input/output error 



When Debug encounters an error, it aborts a background job 
if there is no {ATTEND card. Otherwise it requests further 
commands from the keyboard/printer. At this time. Debug 
will not have modified the environment, allowing the user 
to attempt recovery. (It is assumed that the user will re- 
specify any erroneous commands. ) 



A KEYIN error message issued as the result of an unsolicited 
key-in of DE, or an abort code of DE issued as the result of 
a direct col I on Debug, implies that Debug is not part of the 
system. This can be corrected by queueing in Debug (i.e., 
an unsolicited key-in of Q DEBUG). 



STA 


$ + 6 


LDA 


*$ + 7 


STA 


$+5 


LDA 


$ + 3 


op 


*$ + 3 


B 


$ + 4 


DATA 





DATA 





DATA 


address 



Op is indirect and indexed (6): 



STA 

LDA 

STA 

LDA 

op 

B 

DATA 

DATA 

DATA 



$ + 6 

*$ + 7 

$+5 

$ + 3 

*$ + 3, 1 

$+4 





address 



Class 2 instructions are expanded as follows: 



op 
B 
B 
DATA 



$ + 2 
$ + 3 
*$ + 1 
address 



EXPANSION OF MOVED INSTRUCTIONS 



An instruction that is moved from the point of insertion to 
the insert block will require expansion if its addressing is 
relative or if it is a register copy instruction in which the 
P register is the source. 
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The relative instructions are expanded the same as the 
inserted instructions discussed in the first part of this ap- 
pendix. In the case of Insert Before (IB) or snapshots, 
register copy instructions in which P is the source and the 
clear bit is set will be expanded in one of two ways; 

1 . If the destination is the A register: 



LDA 


$ + 3 


op 


A, A 


B 


$ + 2 


DATA 


a+ 1 



2. If the destination is not the A register: 



STA 


$ + 5 


LDA 


S + 5 


op 


A, R 


LDA 


$ + 2 


B 


$ + 3 


DATA 





DATA 


a+ 1 



In the above expansions, a is the location (point) of the 
insertion and op has the appropriate settings for the incre- 
mentation and inversion bits. 

Debug has no facility for expanding a copy instruction where 
either (1) the P register is the source, the A register is the 
destination, and the clear bit is reset, or (2) the P register 
is the destination and the clear bit is reset. In this case a 
Debug syntax error is generated. 



DEBUG INSERTION STRUCTURE 

An insertion af location a will result in the following: 
a B *)e 

13 DATA r 



moved instruction expansion if lA command 



inserted instructions or snapshot call code 



moved instruction expansion if IB or snapshot 
command 



B *$ + 1 

DATA a + 1 



where j8 is one of the Debug locations in the zero table and 
y is an area in the insertion block. 



DEBUG SNAPSHOT CALLING SEQUENCE 

A snapshot inserted at location awill generate the following 
calling sequence (which is inserted in the insertion block 
similar to a Debug IB command): 



al 
a2 

entry 



DATA D:SNAP 

DATA block 

instruction that was at location a 



WD 
STA 
RCPYI 
B 

DATA 
DATA 

conditions if any 
DATA 

message if any 
DATA 

dumps if any 
DATA 

expanded instruction from location a 
B *$ + 1 

DATA a+ 1 



X'FC (foreground only) 
*a2 
P,A 
*al 
a 
key 

-1 

-1 

-1 



where 



block is the address of the first word of the insertion 

block and is used to save the A register. 

key (bits 0-2) designates type of snapshot: setting 

bit designates stepping snapshot; setting bit 1 
designates line printer snapshot output; and setting 
bit 2 designates keyboard control requested. 

message is the string of EBCDIC characters, if any. 

condition is a string of relational expressions sepa- 

rated by logical operators. A relational expression 
occupies three words as follows: 



loc, reg, or constant 


Ml 


M2 




C 


E 


L 


G 


loc, reg, or constant 



where 



Ml (bits 0-1) designates the type of quantity in the 

first word: 

00 location 

01 register 
10 constant 

M2 (bits 2-3) designates the type of quantity in the 
third word. 

C (bit 12) designates comparison where = arith- 
metic and 1 = logical. 
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E (bit 13) designates equal comparison. 
L (bit 14) designates less than comparison. 
G (bit 15) designates greater than comparison. 
A logical of>erator occupies one word: 

logical or 

1 logical and 

dumps are two-word or three-word items: 

register dump 



or 



1 



register number 



loc 1 



loc 2 



memory dump 



where 

T = 1 designates keyboard/printer and line printer 
output. 

T = designates line printer output. 

A zero register number designates all registers. 
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13. BASIC SPOOLING SYSTEM 



PURPOSE 

The Basic Spooling System (BSS) provides the following; 

1. Allows programs to execute at a speed not limited by 
peripheral speeds by providing a disk buffering file 
during periods of high peripheral utilization. 

2. Through use of the disk buffer file, BSS will maintain 
efficient peripheral utilization by smoothing the peaks 
and valleys of peripheral usage thereby driving per- 
ipheral devices at or near rated speed. 

3. Resolves contentions for a peripheral device between 
foreground and background or between foreground tasks 
themselves such as XSP and IDEN by spooling output 
from one or all of the conflicting tasks. 

4. A convenient point-to-point foreground utility utilizes 
a disk buffer file to synchronize speed and availability 
of peripheral devices. 



IMPLEMENTATION PHILOSOPHY 

A capability is provided whereby tasks may output through 
conventional operational labels or FORTRAN device unit 
numbers and merely through reassignment (or default assign- 
ment), have the output directed to an intermediate spooling 
file. No modification to foreground or background tasks is 
required. 

The disk buffering employed utilizes conventional RBM ran- 
dom files and standard RBM I/O to provide a low overhead, 
high reliability spooling system. The disk allocation is 
circular in nature with output occurring in a first in, first 
out (FIFO) fashion. 



BSS itself operates as a resident, semiresident or nonresident 
foreground task. Multiple copies of BSS may be used to 
provide multiple concurrent spooled operations. A simplified 
overview of BSS operating as a line printer spooler is shown 
in Figure 10. 

BSS is implemented as a foreground task which reads from a 
foreground operational label and writes to a circular disk 
spooling file. Concurrently BSS reads from the disk file and 
outputs through an operational label to a physical device. 
It is through the use of RBM-16logical devices (Version GOO 
and later) that the user task's output operational label is 
connected to the BSS input operational label. A detailed 
overview of a BSS line printer spooler is shown in Figure 11. 

Since the flow of data is initiated and terminated by con- 
ventional RBM operational labels, many variations of BSS are 
possible OS illustrated in Figure 12. 



LOADING BSS 

The control cards for allocating the file and loading BSS are: 

IJOB 

1 PAUSE KEY-IN •SY,S' 

IRADEDIT 

l#ADD UP,COPY,ALL,,R,SY 

!#END 

lASSIGN OV = COPY,UP 

lOLOAD ,F 

!$TCB +C30C,+1200 

i$ROOT ,,BI,3 

!$END 

IRADEDIT 

!# TRUNCATE UP, COPY 

!#END 

IFIN 



User Task 




Circular' 
Disk ; 
Spooling 
File 



BSS 



Line Printer 



Figure 10. Simplified Overview of Line Printer Spooler 
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Circular 
Disk ^ 

Spooling 
File 



dfn-i- 



User Task 



Logical Device 

r----n 



opiabel 



dfr/dfn 



■ opiabel 



li 



BSS 



-opiabel — »>dfn 

_1 



Line Printer 



Figure 11. Detailed Overview of Line Printer Spooler 



With this job stack, BSS will be loaded into a permanent 
file named 'COPY', in the 'UP' area. BSS, when invoked, 
as with aQCOPY keyin, will run at interrupt level X'lOC 
(Interrupt level is user specified). 



Note; The 'Q' keyin can only be used to load programs in 
the 'UP' area. 



ALLOCATING SPOOLING FILES 

A spool file must be allocated in the 'SD' area. Care must 
be taken in naming the spool file. For example, if BSS will 
spool data to the CP foreground opiabel and the default 
spooling file name is being used, the first two characters of 
the file name must be 'CP'. The remaining six characters 
must be 'SPOOL'. The control cards for allocating a CP 
spool file and initiating the copy Ore: 

IJOB 

IRADEDIT 

!#ADD SD,CPSPOOL, 100,,R 

!#END 



Note ; The spooling file must be in the 'R' format. Consult 
Table 21 for spooling file size requirements. 



INITIATING BSS 

BSS may be brought into core as a resident foreground task 
at boot time, or as a semi resident or nonresident foreground 
task through use of the background job stock, or through use 
of the 'Q' keyin (assuming BSS resides in the 'UP' area). 

BSS requires certain fundamental information in order to 
initiate an operation, namely the source of the data, the 
destination for the data, and the name of the intermediate 
spooling file to be used. The relationship of the destination 
operational label and spooling file name is 'op SPOOL', 'SD' 
where op is the destination operational label. The default 
association con be overriden by supplying any spooling file 
name through assembly or load time options. 

If BSS has been assembled with the source, destination, and 
spooling file defined, then no operator intervention is re- 
quired to initiate operation once BSS is loaded. 

Lacking sufficient information, BSS will query the operator 
for source and destination operational labels. If the source 
has not been defined by assembly BSS will prompt with: 



# SPECIFY INPUT 



to which the operator may respond with a two-character 
foreground operational label to be used for BSS input. 

If the destination has not been defined by assembly or if BSS 
will prompt with: 



# SPECIFY OUTPUT 



to which the operator may respond with a two-character 
foreground operational label. BSS will inform the operator 
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Spooling file established by RADEDIT 
known to BSS by assembly or derived 
from destination opib. 




Devlce/dfn association by 

SYSGEN 

DS Keyin 



fe 



Figure 12, Variations of Basic Spooling Systems 



Table 21. Spooling Volume Requirements 



Device 
Type 


Model 
Number 


Rated 
Speed 
(Rec/Min) 


Comp. Char. 
Per 10 Minutes 
Operation 


Sectors Required 
Per 10 Minutes Operation 


Model 
7204 


AAodel 
7242 


Model 
7250 


Model 
32xx 


Readers 


7121 
7122 
7140 


200 

400 

1500 


80K 
160K 
600 K 


225 

450 

1700 


79 
160 
580 


225 

450 

1700 


310 

625 

2350 


Printers 


7450 
3451 
7440 
7445 


225 

350 

800 

1000 


106K 
175K 
400 K 
500K 


295 

490 

1100 

1400 


100 
170 
390 
490 


295 

490 

1100 

1400 


415 

680 

1550 

1950 


Punches 


7165 
7160 


100 
200 


40K 
80K 


110 
225 


390 
79 


110 
225 


155 
310 


Assumptions: 1. 50% overall data compression. 

2. 80-byte records. 

3. 100-byte print records. 



of its last word address, so that the first available address 
for the loading of subsequent foreground programs may be 
determined. However, the last word address will not appear 
if Data Switch 2 is set. 



BSS OPERATION AND CONTROL 

The copy process will proceed immediately after BSS is ini- 
tiated and the source, destination, and spooling file are 
known. 



FORMS CONTROL 

When a *FORM record is encountered in an output stream, 
control will be transferred to the Forms Control Module. 
Upon entry, the 'A' register will contain the return address 
to BSS and the'X' register will point to the following argu- 
ment list 

X'3005' 

1 'OC* 

2 Address of 'FORM' record 

3 Byte length of 'FORM' record 



Upon exit the X-register has the following significance: 
X = -l STOP the stream 

X = -2 SKIP the stream 
Other CONTINUE the stream 

The delivered Forms Control Module will output the *FORM 
record to 'OC and exit with X = -1 to STOP the stream. 

The purpose of isolating this code is to allow installation to 
conveniently add instal lotion dependent code (e.g., special 
forms routing). 

BSS can be controlled with the following keyins: 



#GO 

i^STOP 
#LOCK 



Start operation to foreground opiabel 
XX. Normally, this keyin will only 
be required after a^STOP or #LOCK 
keyin. 

Suspend operation to foreground op- 
label xx. Handy for verifying output. 

Same as '^STOP, but takes effect at 
the conclusion of the current file 
being output. Furthermore, if a 
*^STOP is in effect, this keyin is an 
implied *START. LOCK only applies 
to the output opiabel. 
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#SKIP 



#BACK 



#TERM 



#BIN 
#EBC 

#IVFC 



Skip forward to next EOF in output 
stream. Data skipped in this fashion 
will remain in the spool file. 

Restart output for operational label xx 
at the backup point. The backup point 
is the spooling file holdback point 
(defaults to five granules or previous 
EOF, whichever is greater). 

Terminate the BSS task associated with 
output operational label xx. BSS will 
automatically terminate a copy opera- 
tion when two consecutive EOFs are 
read. All operations are ceased, the 
spooling file directory is updated and 
an M:TERM is performed. 

Perform "write binary" to output 
opiabel. 

Perform "write EBCDIC" to output 
opiabel. 

Append single space vertical format 
byte to output opiabel. 



BSS will not abort if operator intervention is required on the 
output or input opiabel. Instead, BSS will output 



^/7/1/ X^ M-^>^ "-^ "'/ ^"^ )^a>r>^^'n.»f 



CODES 



If the spool file cannot be found, BSS will abort with 
code *F. 

If any fatal errors occur, BSS will abort with the following 
codes: 

"l Error on input 

*0 Error on output 

*F Error on spooling file 



##STOPPED XX 



and simulate a "^STOP key in. The operator may correct the 
problem and then keyin ^START. 



ASSEMBLY OPTIONS 

Various options can be included in BSS at assembly time, 
once the source deck is extracted from the standard release 
tape. These options are described in the Technical Manual 
(and the source listing) and control such items as default 
input and output opiabels as wellasspool filename and area. 

The cost for each concurrent spooled operation is as follows: 

IK core for BSS + 2* spooling file block size +2* 
record size (defaults to 140 bytes). 

3 foreground DFNs for spooling file access, input 

and output. 

2 foreground operational labels. 

1 spooling file (R format). See Table 21 for file 

size requirement. 

1 foreground interrupt level lower in priority 

than lO. 

1 foreground or background DFN for user task. 

1 foreground or background operational label for 

user task. 
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APPENDIX A. ADDITIONAL RBM PROCESSORS 



A set of subsystems and processors is distributed with RBM 
on the transmittal tape. The Overlay Loader, RAD Editor, 
Utility, and Debug processors are described in Chapters 7, 
8, 9, and 12 respectively. XSYMBOL, FORTRAN, ANS 
FORTRAN, and the FORTRAN library are described In their 
ov^^n individual manuals (see the Related Publications page 
of this manual). 

The following additional processors are available on the 
transmittal tape and are described in this appendix: 

Name Purpose 

PLOT A symbiont subsystem for the 7530 or 7531 

graph plotter. (Catalog No. 705780. ) 

INDUMP A stand-alone DUMP program to be used in 

conjunction with RBM. 

COMPRESS A processor for creating blocked compressed 
EBCDIC files on tape, used in preparing the 
source and listing files on the transmittal 
tape. 

EXPAND A processor for expanding the blocked, com- 

pressed files created by COMPRESS to files 
composed of either 80-byte source records or 
134-byte line printer listing records. 

REPLACE A processor for replacing monitor overlays, 

useful in system maintenance (described in 
the RBM/SM Reference Manual, 90 30 36). 



SYMBIONT PLOniNG SYSTEM 

The symbiont plotting system performs circular buffering of 
plotter commands in a RAD or disk file (PLSYMB). A set of 
background subroutines in the FORTRAN subroutine library 
is provided to build the file. The background subroutines 
trigger a foreground task fhat reads the file and drives the 
plotter. The trigger is accomplished via a public library 
subroutine. A set of unsolicited operator key-ins permit 
the operator to supervise the plotting operation. 



UNSOLICITED OPERATOR KEY-INS FOR PLOT 

Key-in Effect 



Key-in 
PL ST (ART) 



Effect 



Stop plotting. 



PLPR (INIT) 



PLHA (LT) 
PLAB (ORT) 



Report the amount of RAD space left in 
the plot file. (Until the end-of-file is 
encountered, the amount of space used 
will be reported.) After the plot data 
have wrapped around, the amount of 
unused space will then be reported. 

Stop plotting immediately. 

Stop plotting immediately and discard 
plot data to the beginning of the next 
plot and halt. 



PLSU (SPEND) Stop plotting at the end of the current 
plot. 

These key-ins have no effect on the background job. 



BASIC PLOTTER CONTROL SUBROUTINES 

This group of four subroutines in the FORTRAN library gives 
the assembly language programmer all of the functions nec- 
essary to draw a plot. They are used by other programs that 
give the programmer more sophisticated functions to simplify 
the task of making a plot. The subroutines generate plotter 
control data and transmit it to the RAD by a call to the 
Monitor I/O. A foreground program is then started that 
reads the data from the RAD and writes it on the plotter. 

If a call is executed that would move the pen off the paper, 
the call is ignored. It is assumed that the pen starts one-half 
inch from the minus-Yedge of the paper (the right border of 
the paper roll . ) 

ENTRY POINTS 

RCPYI P,L 

B PEN UP (register T is changed) 

This entry will cause the pen to be raised if it is down. 

RCPYI P, L 

B PENDN (register T is changed) 

This entry will cause the pen to be lowered if it is up. 

RCPYI P,L 



B 



INITIAL (only register B is saved) 



The current pen position is set to X=0, Y=0, and this posi- 
tion will now be the new plotter reference point. Accumu- 
lated data Is output at this time. Note thatatany time there 
may be a partial buffer of plot data that has not been trans- 
mitted to the device. Therefore, "INITIAL" must be en- 
tered at the end of the plot job to ensure the completion 
of the plot. 

RCPYI P, L 

B MMVE (register T Is changed) 

X Is in register E and Y Is in register A. The pen is moved 
along an approximation to a straight line from Its current 
position to the new location X,Y. X and Y are fixed 
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points, the number of increments from the reference point 
thot is normally the lower left corner of the plot. 

See the FORTRAN library description for a description of 
FORTRAN calls to higher-level PLOT subroutines. 



INDUMP 

INDUMP is a "stand alone" dump facility that provides a 
printed record of the contents of memory when the RBM 
postmortem dump, operator key-in dumps, or the DEBUG 
dumps cannot be used. 



lo is the channel and device number of the line 
printer (format: ccdd). 

nl is the number of lines per page (37 or 52). 

Is is FFFF for a low-speed line printer and for a 

high-speed line printer. 

All parameters are four-character hexadecimal quantities 
except nl, which is decimal. 

If only la is given, the other parameters will be picked up 
from the RBM system, which punches the self-booting 
version. 



INDUMP LOADING TECHNIQUES 

RESIDENT FOREGROUND 

INDUMPmay be loaded into the resident foreground area by 
the usual techniques. It requires 600]^ memory locations. 
The last 200] 5 memory locations may be overwritten if the 
command to display the file control tables in expanded form 
is not to be used. 

RESIDENT HIGH MEMORY 

If the memory size In SYSGEN is indicated to be other than 
a multiple of 8192, INDUMP will automatically be moved 
to KrUNAVBG (beginning of "unavailable" background 
memory) when loaded into the foreground. The space ini- 
tially occupied by INDUMP in the foreground area may 
then be overwritten. 



SELF-LOADING 

A version of INDUMP may be prepared that can be loaded 
using the hardware bootstrap from cards, magnetic tape, or 
paper tape. To do this, the REL version of INDUMP is 
loaded and executed with a IXEQ card with the following 
parameters, which will generate the self-booting version 
on the BO device: 

IXEQ la,ma,fa,ba,cc,oc,lo,nl,ls 



la is the load address. 

ma is the RBM last word address. 

fa is the foreground last word address. 

ba is the background last word address. 

cc is the channel and device number of the boot 
device (format: ccdd). 

oc is the channel and device number of the key- 
board printer (format: ccdd). 



INDUMP OPERATIONS 

INDUMP may be used to provide snapshots of the registers 
and core when DEBUG cannot be used. The call has the form 



f^^^ "iNDUMPFWA + l I FWA= first word 

DATA LOWLIM ^ °^^''^'' 

DATA HIGHLIM 
RETURN 



INDUMP may be called to permit the operator to type in 
commands to it using the calling sequence 

RCPYI P, L 

B INDUMPFWA 



RETURN 



RETURN ON GO 
command 



INDUMP may be started from the console in the event of 
system failure. The procedure is as follows: 

1. Move the COMPUTE switch to the IDLE position. 

2. Copy the values of the P register and PSW (these will 
be input later using the PI command). 

3. Place the startaddress of INDUMP in the data switches. 

4. Select the S register with the register SELECT switch. 

5. Move the clear/Enter switch toCLEAR; then enter. 

6. Place the STORE/FETCH switch in the FETCH posi- 
tion and the ADDRESS HOLD switch in the HOLD 
position. 

7. Momentarily move the COMPUTE switch to the STEP 
positron (3 only). 

8. Move the STORE/tETCH and ADDRESS HOLD switches 
back to NORMAL. 

9. Move the COMPUTE switch to RUN. 
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After INDUMP is started, it will type out the message 
ENTER LIMITS. The operator can then respond with a 
command of the form 

command [hex-value, hex-value]© 

where command may be 

DM Dump RBM area. 

DF Dump Foreground area, including Public 
Library. 

DB Dump Background area. 

DA Dump all of core up to KrUNAVBG. 

ZM Zero RBM area, including Public Library. 

ZF Zero Foreground area. 

ZB Zero Background area. 

ZA Zero all of core up to KrUNAVBG. 

PI Place the first hex value in the stored P regis- 

ter location and the second in the stored PSW 
location. 



GO Restart operation of RBM with values given by 
PI command or obtained from call. 



or 110-byte listing record on the EO device file. The 
EXPAND processor is invoked by 



/l EXPAND {^|,ident[,n] 



DT Dump file control tables. 



After a dump or zeroing between limits, the ENTER LIMITS 
message will be retyped and a new command may be entered. 
If hex values are specified on any command, they will over- 
ride the command's implicit limits. 



COMPRESS 

The COMPRESS processor reduces the length of the RBM 
distribution tape. COMPRESS reads records from the SI 
file or device, expands them to 134 bytes by filling with 
blanks on the right, then blank-compresses and blocks those 
records into 1024-byte blocks. It then outputs those blocks 
to the CO device file. 



EXPAND 

EXPAND takes the blocked records from CI formed by 
COMPRESS and generates either 80-byte source records 



where 

S indicates that the source records are to be writ- 

ten on the EO operational label. 

L indicates that the listing records are to be writ- 
ten on the EO operational label. 

ident is a 1-8 character identifier that exists be- 

ginning in column 73 of the source file. 

n indicates the number of files to be expanded. 

The operational labels CI (Compressed Input) and EO (Ex- 
ternal Output) must be assigned to the appropriate device 
file numbers before executing EXPAND. 

The EXPAND processor searches the CI device until it finds 
the specified ident. If a double EOF is encountered, the 
tape will be rewound and a second search made. If the 
ident is not found on the second search, an appropriate 
message is output on OC. 

When the selected ident is located, the file is decompressed 
and output on the EO device according to the selection 
parameter S or L. 

For example, the command 

! EXPAND L,TOC 



will cause the EXPAND processor to list the TOC (Table 
of Contents file on EO. Similarly, the command 

! "EXPAND L,EXP,3 



will cause the EXPAND processor to list three files, be- 
ginning with EXPAND. 

To obtain a source magnetic tape, assign EO to a magnetic 
tape and input 

! EXPAND S,EXP 



which will produce a source file acceptable as symbolic 
input to XSYMBOL. 
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^ 



X 



The following table should be used to determine the standard assignments for an installation's background operations! labdU and to determine which 
operational labels, if any, should be suppressed by being assigned to file 0, The standard operational labels are defined under the {ASSIGN commtsnd 
in Chapter 2, 



^"^v,^,^ Operational 

„ ^^^^^ Label 
Processor ^■*».»,.^^ 


Device 
Number 1 


CC 


SI 


UI 


AI 


BI 


BO 


UO 


LL 


DO 


RBM (Job Control 
Processor) 


ReqdA*/rite 
unsolicited 
key-in 


Read 

Control 

Commands 






Read 

Absolute 

Binary 


Read Object 
modules with 
I REL command 






Write Control 

Command 

Images 




XSYMBOL^ 






Read Source 
Statements 


Read 

Update 

Records 






Write Reioc, 
Binary 




Usad for CC 
Diagnostics 


Write XSYMBOL 
Error Messages 


Concordance 






Read Source 
Statements 














Write Concordance 
Error Messqges^"^ 


Basic FORTRAN IV or 
ANS FORTRAN IV 






Read Source 
Statements 








Write Reloc. 
Binary 






Moth Library 










i 






Write Library 
Error Messages 


Overlay Loader 




Read 

Control 

Commands 










i 


Log ContnsI 
Commands 


Write Loader Error 
Messages'" 


RAD Editor 




Read 

Control 

Commands 








Object Module 
Input to System 
and User 
Libraries 


Output Copies of Ob- 1 
ject Modules from Sys- ' 
tern and User Libraries • 


Log Control 
Commands 


Write Error Mes- 
sages and 
operator key-ins 


Utility Executive 






Read 

Control 

Commands 












Log Control Write Utility Error 
Commands Message''^^ 


Utility Copy ^*''* 






Read Control 
Commands 


Read 
Input 














Utility RECEDIT 






Read Control 
Commands and 
Modlfic Input 


Read 
Input 








Write 
Output 






Utility OMEDIT 






Read Control 
Commands 


Read 
Input 




Read Binary 
Modific. Input 




Write 
Output 






Utility DUMP 






Read Control 
Commands 


Read 
Input 














Utility SEQEDIT 






Read Update 
Data 


Read 
Input 








Write 
Output 






Uses opiabel SO to output source statements (updated, if applicable). Suppressed if assigned to same device as OC, 
^"^Suppressed if assianed to same device as LO. May use any opigbel for output. 



-u 



X 

00 



m 

1^ 









^""V.^,^^ Operational 

^•\^^ Label 
Processor ^^«v^^ 


LO 


LI 


PM 


OC 


XI PI 


OV 


X2 


X3 


S2 


GO 


X4 


X5 


RBM (Job Control 
Processor) 






Write Abso- 
lute Binary 
Monitor (SYS- 
GEN only) 


Write Proces- 
sor and Mon- 
itor Abort 
Messages 




Read RBM 
Overlays 


Write Pro- 
gram Loaded 
by lABS 
Command 






■ 


Write Ob- 
ject Mod- 
ule with 
IREL 
command 






XSYMBOL 


WRITE Listing 
Output and 
XSYMBOL 
Error Messages 






Operator 
Commu-' 
nications 


Intermediate 
Output 


Read | Output 
XSYMBOL 1 Encoded 
Overlays i Text 


Output Output 
Program Standard 
Locals Proce- 
dures 


Output 
Execution 
Object 
Language 






Concordance 


Write Listing 
Output and 
Concordance 
Error Messages 








■ 1 












Basic FORTRAN IV or 
ANS FORTRAN IV 


Write Listing 
Output and 
FORTRAN 
Error Messages 




i 


Intermediate Read 
Output ' FORTRAN ! 
Overlays 








Output 
Execution 
Object 
Language 






Math Library 


Write Library 
Error Messages 




1 Operator 
1 Commu- 
1 nications 


; 
















Overlay Loader 


Write Maps 


Read Reloc. 
Binary 
Library File 


i Operator 
! Commu- 

; nications 

i , 


■ : 

Contains Sym- \ Read 
bol Table for j OLOAD 
each segment Overlays 


Write 
Core 
Images 


Read 

MODIR 

File 






Read 

Reloc. 

Binary 






RAD Editor 


Write Maps 
and Dumps 
of Files 






Operator 
Commu- 
nications 


Replace Files i Read RAD 
and Maintain | Editor 
Libraries Overlays 




Replace 
Files and 
Maintain 
Libraries 


Maintain Li- 
braries and 
Update Di- 
rectories 






Maintain 
Libraries 




L>tillty Executive 


Write Utility 
Error Messages, 
Control Com- 
mand Images and 
other Output 






Operator 
Commu- 
nications 


Read 

Utility 

Overlays 














Prestore 
Commands 
From SI 


Utility Copy 
























Input 

for 

Verify 




Utility RECEDIT 


Write Modi- 
fication Log 


























Utility OMEDIT 


Write Module Log 
















Prestore BI 










Utility DUMP 


Write Dump 


























Utility SEQEDIT 


Write Listing 


















. 









APPENDIX C. SYSTEM ZERO TABLE AND CONSTANTS 



Table C-I. Monitor Zero Table 



Address 


Name 


Purpose and Assignment 


Dec. 


Hex. 



1 
2 
3 
4 
5 
6 
7 
8 



1 
2 
3 
4 
5 
6 
7 
8 


K:AC 

K:AC1 

K:AC2 

K:AC3 

KrFFLG 

K:BASE 

K:TCB 


Reserved for Monitor Use. 

Pointer to Current Floating Accumulator. 

Pointer to Current Floating Accumulator (1). 

Pointer to Current Floating Accumulator (2). 

Pointer to Current Floating Accumulator (3). 

Pointer to Current Floating Flags. 

Pointer to Current Task Reentrant Temp Stock. 

Pointer to Current Task TCB. 

Reserved for Monitor use. 


9 
63 


9 
3F 




Standard Constants for Foreground, Monitor, and Background 
Use (see Table C-2 for complete list). 


64 
99 


40 
63 




IOCS Pointers and Constants. 


100 
132 


64 
84 




Reserved for Monitor Use. 


133 
134 
135 


85 
86 
87 




Debug Transfer Vector D:KEY. 
Debug Transfer Vector DrCARD. 
Debug Transfer Vector DrSNAP. 


136 
167 


88 
A7 




Reserved for Debug Use. 


168 
198 


A8 
C6 




Real-Time Foreground User Storage (reserved for foreground 
communication between foreground and background or for 
address literals or constants). 
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Table C-1. Monitor Zero Table (cont. ) 



Address 


Name 


Purpose and Assignment 


Dec. 


Hex. 


199 
225 


C7 
El 




Monitor Service Routines Transfer Vectors (see Table 7 for list). 


226 
251 


E2 
FB 




Monitor Constants (see Table C-3). 


252 
255 


FC 
FF 




Counter Interrupt Locations (optional). 







Table C-2. Standard Constants 










Address 


Value 


Address 


Value 


Dec. 


Hex. 


Dec. 


Hex. 


Dec. 


Hex. 


Dec. 


Hex. 


9 


9 


32768 


8000 


20 




14 


16 


10 


10 


A 


16384 


4000 


21 




15 


8 


8 


11 


B 


8192 


2000 


22 




16 


4 


4 


12 


C 


4096 


1000 


23 




17 


2 


2 


13 


D 


2048 


800 


24 




18 


1 


1 


14 


E 


1024 


400 


25 




19 








15 


F 


512 


200 


26 




lA 


-1 


FFFF 


16 


10 


256 


100 


27 




16 


-2 


FFFE 


17 


11 


128 


80 


28 




IC 


3 


3 


18 


12 


64 


40 


29 




ID 


-3 


FFFD 


19 


13 


32 


20 


30 




IE 


-4 


FFFC 



Appendix C 153 



Table C-2. Standard Constants (cent.) 



Address 


Vol 


ue 


Addr^s 


Value 


Dec. 


Hex. 


Dec. 


Hex. 


Dec- 


Hex. 


Dec. 


Hex. 


31 


IF 


5 


5 


48 


30 


H 


E 


32 


20 


-5 


FFFB 


49 


31 


-14 


FFF2 


33 


21 


6 


6 


50 


32 


15 


F 


34 


22 


-6 


FFFA 


51 


33 


-15 


FFF1 


35 


23 


7 


7 


52 


34 


-16 


FFFO 


36 


24 


-7 


FFF9 


53 


35 


32767 


7FFF 


37 


25 


-8 


FFF8 


54 


36 


32512 


7FO0 


38 


26 


9 


9 


55 


37 


33023 


80FF 


39 


27 


-9 


FFF7 


56 


38 


65280 


FFOO 


40 


28 


10 


A 


57 


39 


255 


OOFF 


41 


29 


-10 


FFF6 


58 


3A 


61440 


FOOO 


42 


2A 


n 


B 


59 


38 


3840 


OFOO 


43 


2B 


-11 


FFF5 


60 


3C 


240 


OOFO 


44 


2C 


12 


C 


61 


3D 


49152 


COOO 


45 


20 


-12 


FFF4 


62 


3E 


31 


IF 


46 


2£ 


13 


D 


63 


3F 


127 


7F 


47 


2F 


-13 


FFF3 











Table C-3. Monitor Constants 



Address 


Nome 






Dec. 


Hex. 


Purpose 


226 
227 
228 
229 
230 
231 
232 


E2 
E3 
E4 
E5 
E6 
E7 
E8 


KrMASTD 
K:PAGE 
KrBACBUF 
K.-BACKP 




Reserved for Monitor use. 

Pointer to Master Dictionary. 

Number of Lines/Printer Page (SYSGEN Parameter). 

Background I/O Buffer Pool FWA. 

Protected Background FWA (Start of TCB). 

Reserved for Monitor use- 
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Table C-3. Monitor Constants (cont.) 


Address 


Name 


Purpose 


Dec. 


Hex. 


233 


E9 


K.-PLFWA 


Public Library FWA. 


234 


EA 


KrRFFWA 


Resident Foreground FWA. 


235 


EB 


K.-NFFWA 


Nonresident Foreground FWA. 


236 

• 


EC 


KrBACKBG 


Unprotected Background FWA. 


237 


ED 


KtUNAVBG 


Unavailable Memory FWA. 


238 


EE 


KrBLOCK 


Size of Blocking Buffer in Words (180 or 512). 


239 


EF 


K.-FEF 


FORTRAN Background Error Severity (1). 


240 


FO 


K:TVECT 


Pointer to Transfer Vector Table. 


241 


Fl 


KrFWA 


Legal TVECT Entries to FGD-FWA. 


242 


F2 


K:LWA 


Legal TVECT Entries to FBD-LWA+1. 


243 


F3 


F:FWA1 


TVECT FWA for T Register Check. 


244 


F4 


K.-LWAl 


TVECT LWA+1 for T Register Check. 


245 


F5 


KiOLOAD 


Pointer to RBM OV.-LOAD Table. 


246 


F6 


P:CST9 


Reserved for RBM use. 


247 


F7 


KrCCBUF 


Address of Control Card Buffer. 


248 


F8 


KrNRFQ 


Pointer to Nonresident Foreground Queue Table. 


249 


F9 


KiNEXT 


Next Available Sector in BT Area. 


250 


FA 


K:PROTCT 


Pointer to Protection Register Table. 


251 


FB 


KiPMDTBL 


Pointer to Postmortem Dump Table. 


405 


195 


KrCPU 


CPU Type and Hardware Options. 


These names are as defined in the RBM Monitor and are 
these names must be defined in the user program (e.g. , 


not system definitions. Any references to these locations by 
K:PAGE EQU X'E5'). 


Relationships for Monitor Constants: 




1 . (KrPLFWA) = LWA+1 of RBM- 


4. (KrBACKP) = LWA+1 of Nonresident Foreground. 


2. (KrRFFWA) = LWA+1 of Public Library. 


5. (KiBACKBG) = (KtBACKP) + 39. 


3. (KrNFFWA) - LWA+1 of Resident Foreground 


6. (KrCCBUF) = (KrUNAVBG) - 62. 
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APPENDIX D. ERROR MESSAGES, WARNING MESSAGES, AND ABORT CODES 



RBM MESSAGES AND ABORT CODES 

JCP CONTROL COMMAND DIAGNOSTICS 

The following error messages may appear on the background 
DO device as a result of an error condition detected by 
JCP. These diagnostics supplement the abort or attend- 
mode error codes printed by JCP. 



Message 



Comments/ 
Associated Commands 



.BK OPLB/bFN TBL FULL ASSIGN, DEFINE, default 

assignments for system 
processors 

.FG OPLB/bFN TBL FULL ASSIGN 



.ILLCrCODE 

.ILLCrTCB 

.ILL RAD SEQUENCE 

. IN V COMMAND 

.INV OP LB OR DFN 
• INV OPTION 



C: (Connect) 

C: (Connect) 

WEOF, REWIND, UNLOAD, 
FBACK, FSKIP, RBACK, RSKIP 

Command not recognized as 
a Monitor service command, 
system processor, or user 
processor. 

ASSIGN, DEFINE, WEOF, 
REWIND, UNLOAD, FBACK, 
FSKIP, RBACK, RSKIP 

An invalid option has been 
encountered on a Monitor 
service command 



Message 

.NO 'FG' KEY-IN 

• NO 'SY' KEY -IN 



Comments/ 
Associated Commands 

ASSIGN, XEQ,C: 

WEOF, ABS, REL 



.OP NOT MEANINGFUL WEOF, REWIND, UNLOAD, 

FBACK, FSKIP, RBACK, 
RSKIP 

.RAD TEMP OVERFLOW DEFINE, default assignments 

for system processors 



RBM ABORT CODES 

The codes listed in Table D-1 are the standard background- 
job abort codes issued by RBM for abort conditions detected 
by the Monitor, JCP, RAD Editor, and Utility, and also 
by tbe Basic FORTRAN IV compiler and the Extended Sym- 
bol assembler. Note that the codes for abort conditions 
detected by the Overlay Loader are listed separately in 
Table D-3. 

The abort codes appear in a standard abort message of the 
form 

l.'BKG XX ABORT loc zzzz 

where 

XX is the abort code. 

zzzz is the location at which the abort occurred. 



Table D-l. RBM Abort Codes 



Code 


Meaning 


AE 


Assignment error during loading; improper l/O assignment or invalid format. 


AI 


Irrecoverable I/O error on device assigned to operational label AI. 


BI 


Irrecoverable I/O error on BI device. 


BO 


Irrecoverable I/O error on BO device. 


cc 


Error in control cards or in sequence of job stack. 


CK 


Irrecoverable error while checkpointing. 


CS 


Checksum error from absolute or relocatable binary input. 


DE 


Debug not resident when requested. 
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Table D-1 . RBM Abort Codes (cont.) 



Code 


Meaning 


ER 


Operator-recognized error condition. 




ES 


FORTRAN library abort^ 




FC 


Illegal FORTRAN control cord. 




FS 


FORTRAN abort^ 




FX 


A control card was encountered in the FORTRAN source deck. 




GO 


Irrecoverable error on output to the GO file when using a !REL command. 




HX 


Illegal hex parameter. 




IE 


Error in input deck. (Usually, a negative ORG item has been input. ) 




lO 


Irrecoverable l/O error. 




LO 


Irrecoverable I/O error on LO device. 




MF 


Machine fault interrupt has occurred. 




NA 


Nonexistent address used by background program (530 systems only). 




NP 


No patch area has been allocated. 




OP 


Operator abort, from unsolicited key-in. 




OV 


Problem with device assigned to operational label OV. (Normally, OV is assigned to the RAD. 


) 


PE 


Parity error in background (perhaps attempting to read from unavailable memory). 




PO 


The patch area has overflowed. 




PU 


Number of argument greater than temporary storage in M:PUSH . 




PV 


Protection violation. 




RE 


RAD Editor abort^ 




RS 


Irrecoverable error during restart. 




SI 


Irrecoverable input error in SI device. 




SQ 


Sequence error in absolute or relocatable binary deck. 




TL 


Background program time limit exceeded. 


" 


TS 


Temp stack overflow. 




TY 


Invalid load type in ABS deck. 




UT 


Utility subsystem abort . 




XE 


Fatal error in loading. 




XS 


Extended Symbol abort . 




After the ab 


ort code is output, the processor will exit via the RBM routine M:ABORT. 




Note: The processing of the job stack is discontinued following any abort. If an "ATTEND" control command 


was 


n effect, the Monitor will enter an "idle" state. This will allow the operator to correct the 


prob- 


lem ( 


and restart the job. If not in "attend", the Job Control Processor will read commands until a 




!JOE 


or !FIN command is encountered. All control commands encountered prior to the {JOB or 


!FIN 


comrr 


land will be logged with an indication (">" will precede the command) that they have been 




Fgnor 


ed. 
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OVERLAY LOADER MESSAGES AND ABORT CODES 

I/O ERROR MESSAGE 

The I/O error message has the following format. It is 
fol lowed by a " ! !BKGD lO ABORT. . . " message 

** opib device type and number diagnostic 

where 

$$ identifies Overlay Loader as the message source. 

op lb is the operational label of the device or file 
on which the error occurred. 

device type and number identify the device. 

diagnostic is an error diagnostic (listed below) cor- 

responding to an I/O completion code. ^ 

The fol lowing diagnostics may occur: 
UNRECOVERABLE I/O ERROR 
CALLING SEQUENCE ERROR 
INVALID OPERATIONAL LABEL 
OL = 0, OR OPERAT MEANINGLESS 
ILLEGAL END OF FILE 
END OF TAPE 

INCORRECT RECORD LENGTH 
ILLEGAL BUFFERING 



See Table 10, "I/O Completion Codes", in Chapter 4. 



WRITE PROTECTED 
BEGINNING OF TAPE 
ILLEGAL RAD SEQUENCE 
BLOCKING BUFFER UNAVAILABLE 

An example of the I/O abort message is given below: 
$$ BI MTDO END OF TAPE 
!!BKGD lO ABORT, LOC 3F4C 

where 

BI is the opIb. 

MTDO is the device name and number. 

END OF TAPE is the diagnostic. 
3F4C is the I/O abort location. 



LOADER ERROR MESSAGES 

The Overlay Loader loading error messages are listed in 
Table D-2. 

The type of message is indicated as follows: 

A Error causing an Overlay Loader abort, i.e., 
error message is followed by an abort message. 

R Error or condition causing an operator response 

to be solicited, i.e., the message is followed 
by an RBM "11 BEGIN WAIT" message. 

W Warning message only; loading proceeds. 



Table D-2. Loader Error Messages 



Message 


Type 


Meaning 


$$ LIBSYM UNDEFINED* 
(OLOAD only) 


A 


There was no file entry on the system Data area of the RAD or disk pack 
for the LIBSYM table. Overlay Loader aborts with code PL. 


$$ ERR BU 


W 


Sufficient blocking buffer space unavailable. Severity level is set. 


$$ ERR CC 


R 


A control command card has a format or parameter error. An S key-in 
causes the next control command to be read in from CC. This may be 
a corrected command to replace the one in error." 


$$ ERR CS 


R 


There was a checksum error on a binary record. An S key-in causes the 
record to be reread. 


$$ ERR CO 


W 


Foreground COMMON, based below root, overlaps root. Warning only, 
no severity level set. 


$$ ERR CI 


W 


The Loader has encountered COMMON allocation in the root of a non- 
resident foreground program with the R option specified but without cmn 
specified on the ! OLOAD command. The R specification Is ignored and . 
COMMON base is set =K:BACKP minus the size of COMMON. 
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Table 


D-2. Loader Error Messages (cont.) 


Message 


Type 


Meaning 


$$ ERR IB 


R 


Illegal binary format (that is, the first word was not 'FF' or '9F') was 
detected. An S key-in causes the record to be reread.*'' 


$$ ERR ID 


R 


The indent on tfie binary module fust loaded does not compare with the 
indent specified on the !$LD command. On an S key-in, the Loader 
accepts tfie binary module as is and continues processing. 


$$ ERR IS 


RorA 


Control commands were improperly sequenced in the control command 
stack. An S key-in causes the next control command to be read. How- 
ever, if the sequence error was due to a SEG command, the Loader aborts. 


$$ ERR RC 


W 


Trailing reserve overlapped COMMON; no error severity level is set. 


$$ ERR SQ 


R 


There was an incorrect sequence number on a binary record. An S key-in 
causes the record to be reread. 


$$ ERR TA 


W 


No transfer address was encountered in the loading of the root program 
portion. The Loader sets a default transfer address as the first word of the 
program and generated an error severity level of one. 


$$ ERR UR^ 


W 


There were unsatisfied references in the path. 


$$ TOO MANY DEFS^ 
(OLOAD only) 


A 


There were more DEFs in the Public Library than were allocated at sys- 
tem generation. Overlay Loader aborts with code PL. 


$$ PUBLIB NOT LOADED 
(OLOAD only) 


A 


Severity level greater than zero was encountered or generated during 
Public Library loading. Overlay Loader aborts with code PL. 


$$ ERR US 


W 


A symbol table entry was not recognized. 


$$ ERR XL 


W 


Exioc of program is outside the appropriate area. 


This message (OLOAD only) 
the disk. If the alarm occurs 


may be writter 
, the Public Li 


1 on DO during writing of the Public Library, LIBSYM, or TVECT table onto 
brary was not completely written and will have to be reloaded after the 


error is corrected. 






The Loader does not reposition tfie record for rereading. If paper tape or cards are repositioned, the record is reread; 
if they are not repositioned, the next record is read. If the record is on disk or magnetic tape, the Monitor l/O error 
recovery procedures positions to the beginning of the next record. However, the WAIT permits the taking of dumps, 
etc., before changing the environment. 



LOADER ABORT CODES 

Table D-3 lists the abort codes specific to conditions de- 
tected by the Overlay Loader during the loading process. 
The codes appear in the standard abort message of the 
form 

!!BKG XX ABORT LOC zzzz 

where 

XX is tfie abort code. 

zzzz is the location at which the abort occurred 
(if significant). 



RAD EDITOR MESSAGES AND ABORT CODE 

The RAD Editor error and warning messages are listed in 
Table D-4. The type of message is indicated as follows: 

A Error causing a RAD Editor abort, i.e., error 
message Is followed by an abort message. 

R Error causing an operator response tobe solicited, 

(usually only if attend mode is in effect, abort 
otherwise), i.e., error message is followed by 
an RBM "! IBEGIN WAIT" message. 

W Warning message only; RAD editing proceeds. 

AC Error causing RAD Editor to abort the current 
command processing; reads next command. 
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Table D-3. Overlay Looder Abort Codes 



Code 


Meaning 


Al 


Error In accessing the RBMSYM file- 




A2 


Error in accessing the LIBSYM file. 




A3 


Error in accessing the EBCDIC library file. 




A4 


Error in accessing the DEFREF library file. 


These codes are frequently caused by an insufficient 
' allocation of RAD Device File Numbers at SYSGEN . 


A5 


Error in accessing the MODIR library file. 




A6 


No blocking buffer is available for the RBMID file. 




A8 


Error in accessing the TVECT file. -^ 




A9 


Error in closing the RBMID file. 


BB 


Cannot assign blocking buffer for input. 


CM^ 


A COMMON displacement or size larger than that stipulated on the lOLOAD command or in a start 




item was detected. (Background abort only. ) 


DS^^ 


The same identifier was used to name two different segments. 


EF^^ 


An illegal end-of-file was detected. 


EL 


Excessive Length. The run-time size of the program being loaded has exceeded the specified or default 




limit (see Chapter 7, Table 19). 


IT 


An illegal item type was detected. 


LI 


The library files cannot be loaded because of incorrect construction of the library. 


L2^ 


Labeled COMMON data (subtype 2) is for a block outside the current segment. 


L3^^ 


The number of Labeled COMMON indicies allowable per module has been exceeded (currently 




limited to 40). 


l/^ 


Block size prescribed (subtype 0) is greater than that already allocated. 


L5^^ 


Labeled COMMON symbol Is defined as a program symbol within the current path. 


16' 


Labeled COMMON data from a Library Module (roof) is intended for a block allocated in the program 




section of the root. 


L8^^ 


An external DEF was encountered with the same label as a prior labeled COMMON block. 


LS 


Library search overflow. The number of unique library definitions and references along a program path 




exceed 300. 


On 


An Overlay Loader function that prevents proceeding has occurred. The number of the overlay in which 




the malfunction occurred is indicated by n. 


PL 


OLOAD was unable to write the Public Library, the LIBSYM, or the TVECT files onto the RAD. 


RL 


Root of excessive length. 


RS 


Overlay Loader unable to correctly read the RBMSYM file from the SD area. 


SA^^ 


Not enough segments were allocated for the task. The segments parameter of the lOLOAD command 




should be larger. 
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Table D-3. Overlay Loader Abort Codes (cont. ) 



Code 



Meaning 



SD 

SE 

SG^^ 

SL 

TQt^ 

UN^^ 



Next segment of the Overlay Loader cannot be loaded. 

Input ROM had an error severity level greater than zero. 

Format or parameter error was detected on o !$SEG command. 

The length of a segment was excessive, (see !$ROOTand !$SEG commands for maximum segment size). 

There was a table overflow. Decrease the size of the program (OLOAD only) or reduce the number of 
external symbols. 

The number (on the !$SEG card) of the segment to which this one is attached has not been defined. 



Loading will continue until terminated but the load program will not be generated and exit will be through MrABORT. 

Loading will be terminated and, if a map has been requested, it will follow to the point of termination, after which 
the exit will be through MrABORT. 



tt 



Table D-4. RAD Editor Error and Warning Messages 



Message 


Type 


Meaning 


## ASSIGN ERR: area, 
filename 


A 


The RAD Editor was unable to assign an operational label to o filename because 
the number of available RAD or disk pack device-file numbers is insufficient or 
because the specified file does not exist. 


** BAD IDENT 


A 


The object module on BI does not have the same "identification" in the start 
module item. 


##BTL DOES NOT EXIST 
ON DEVICE 


A 


The disk pack does not have a bad track list written in sector 2 which is 
necessary for I^GDTRACK or l#BDTRACK processing. 


##BTL OVERFLOW 


W 


There are more flawed tracks on the disk pack than there are available alternate 
tracks. 


## CALLSEQ ERRoplb 


A 


A calling sequence error occurred for input/output on the device having the 
operational label opib. 


## CAN'T FIND area, 
filename 


W 


An attempt was made to save, clear, truncate, or delete a file whose name 
does not exist in the specified area, or the specified area does not exist. 


## CHCK WRITE ERR 


A 


A check write error occurred (that is, data recorded on the disk could not be 
verified). 


## CKSM ERR 


RorA 


The last record in the object module being read from BI has a checksum error. 
If the job is in attend mode, operator response is solicited; an operator response 
of S causes the Editor to read the next record from BI. 


## CLEARING 
## DELETING 
## SQUEEZING 
## TRUNCATING. 


area 


R 


These messages (followed by ! IBEGIN WAIT) are output wlienever the indicated 
operation is started. A key-in of S allows the operation to proceed. 


## CORE OVERFLOW 


A 


The last command cannot be processed for lack of background space. 


## DONE 


W 


Message is output when the operation is completed. 
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Tabte D-4. RAD Editor Error and Warning Messages (conf. ) 



Message 


Type 


Meaning 


## DUP IDENT 


A 


The last object module read from BI cannot be added to the library with a 
I'^'LADD command because it is already in the library. 


## DUPLICATE: area, 
filename 


W 


An attempt was made to add a file whose name already exists for this area. 


## EDIT ERR 


A 


File directory data on the disk has been rendered involid. 


## EMPTY opib 


R 


The device assigned to the operational label is in manual mode. 


## EOF opIb 


A 


An unexpected end-of-file was encountered on the device having the 
operational label opIb. 


## EOF READ FILE 


W 


An EOF has been encountered on the input file. Copying will continue until 
EOT on the read file or EOT on the write file is encountered. 


## EOT opIb 


A 


An unexpected end-of-tape was encountered on the device having the 
operational label opIb. 


## EOT WRITE FILE 


W 


An unexpected EOT occurred on the file currently receiving data. This is a 
warning to the user that the output file is smaller than the input file (as in 
!"'FC0PY) but that the data already written is correct. The RAD Editor reads 
the next command. 


## {^y} PROTECTED: 
area, filename 


R 


The specified area or filename has an SY or FG write protect code and an SY 
key-in is not in effect. This message will be followed by [BEGIN WAIT. 


## FORMAT CONFLICT: 
area, filename 


W 


The filename being restored to the area conflicts in format or record size with 
the existing filename in the area. 


## xxxx HAS ALT 


W 


An alternate track already exists in the bad track list for track xxxx. 


## IDENT NOT FOUND 


W 


The identification in start module item is blank, or there is no object module 
on BI. 


## ILLEG BIN 


A 


An illegal binary record (first byte not X'FF' or X'9F') has been read in an 
object module on BI. RAD Editor aborts. 


## INV CTRL 


W 


Control command is invalid. It cannot be recognized by RAD Editor or has 
incorrect syntax. 


## INVI/OOPoplb 


A 


An invalid input/output operation was attempted on the device having the 
operational label opIb. 


## LENGTH ERRoplb 


A 


A record of incorrect length was read from or written on the device having the 
operational label opIb. 


## LOAD ERR 


A 


The required RAD Editor overlay cannot be loaded. 


## LOC pppp ERR:0001 


A 


During the !*^GDTRACK-!#BDTRACK processing, the device number specified 
was 1) not found in the system tables or, 2) was found to be a RAD rather than 
a disk pack. 


## LOC pppp ERR:0002 


A 


An end-of-tape was detected while writing the bad track list on sector 2. 


## LOC pppp ERR:0003 


A 


An end-of-tape was detected while reading the bad track list on sector 2. 


## LOC pppp ERR:0010 


A 


An error was detected while assigning the operational label XI to the device 
number specified in the !#GDTRACK or I^BDTRACK command. 
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Table D-4. RAD Editor Error and Warning Messages (cent. ) 



Message 


Type 


Mean ing 


## LOG pppp ERR:0100 


AG 


A I^GDTRAGK or I^BDTRAGK command requires a minimum of fwo fields 
(e.g., 0< DN <FF plus a track number or 'ALL'). 


## LOG pppp ERR:0102 


A 


The device number field on the I^GDTRAGK or !#BDTRAGK command is a 
null field or zero. 


## LOG pppp ERR.-OllO 


AG 


The track number on a I^GDTRAGK or I'^BDTRAGK command must be numeric 
and 0< track ^ S maximum track number for the device. 


## LOG pppp ERR:Oin 


AG 


User tried to I^GDTRAGK or !#BDTRAGK track zero. 


## LOG pppp ERR:0120 


A 


An I/O error occurred during the write headers on the disk pock. 


° ## LOG pppp ERR:0130 


A 


A RAD device number was used on a I^GDTRAGK or !#BDTRAGK command. 


## LOG pppp ERR:0140 


AG 


User tried to create a bad track list on an inappropriate disk pack (Model 7242 
and 7246). 


## LOG pppp ERR:0150 


A 


An I/O error occurred during the read headers on the disk pack. 


'^^ LOG pppp ERR:0170 


AG 


User tried to use command I'^BDTRAGK -idn,ALL on an inappropriate disk pock 
(Model 7251 or 7252). 


## LOG ppppERR:0200 


A 


RAD Editor cannot find the device number specified on the ! '^INITIALIZE 
command in the system tables. 


## LOG pppp ERR:0210 


A 


The device number on the {^INITIALIZE command specifies a RAD. 


## LOG pppp ERR:0230 


A 


The bad track list for the specified device number does not exist in the system 
tables. 


## LOG ppppERR:0260 


A 


No device format exists for the specified device number. 


## LOG pppp ERR:0261 


A 


An undefined device format code was found in the system tables. 


## LOG pppp ERR:0300 


A 


During the PDPGOPY processing, no device format code was found for the 
specified disk pack. 


## LOG ppppERR:0310 


A 


The device number specified in the I'^DPGOPY command was not found in the 
I/O Control Subtable. 


## MAX TRAGK 
# EXGEEDED 


W 


User has tried to I^GDTRAGK or 1#BDTRAGK using a track that does not exist 
on the disk pack. 


## NO ALTERNATE 


W 


An alternate track is not available for execution of the I^BDTRAGK command. 


*# NO BLOGK opib 


A 


No blocking buffer is available for the file assigned to the operational label 
opIb. 


## NO GD/BD TRAGK 
ON TRAGK 


W 


User cannot 1*^GDTRAGK or I^BDTRAGK track zero. 


## OVERFLOW: area, 
filename 


W 


Allocation of the amount of storage indicated by the file parameter on the 
l*ADD command or restoration of a file not currently allocated would cause 
the permanent area to overflow, or a library file has overflowed during execu- 
tion of a I^LAOD command. 


## PARAMERR 


w 


Gontrol command has a parameter error. A parameter has Incorrect content, 
has been omitted, or is not consistent with the other parameters. 
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Tabfe D-4. RAD Editor Error and Warning Messages (cont. ) 



Message 


Type 


Meaning 


## OPEN FILE, NO 
CHANGE: area, nie 


W 


The file has an operational Jabel assigned to it when a {^DELETE, {^TRUNCATE, 
{#CLEAR or {^SQUEEZE corranorKl is executed and the position of the fife 
changed. The file must be reossigned before it is used by another processor. 


** SAVE TAPE NOT 
AT LOAD POINT 


R 


The save tape was not at load point when the f^SAVE command was encoun- 
tered and execution commenced. 


## SEQ ERR 


RorA 


The last record in the object module being read from BI has a sequence error. 


## SZ ERR 


A 


The object module on BI cannot be placed in the library because it has more 
than 61 external definitions and references. 


## TRACK ZERO BAD 


W 


During construction of a bad track list, track zero is found to be flawed. 


## TRK xxxx NOT IN 

BTL 


W 


User has tried to !*GDTRACK a track that does not exist in the bad track list. 


## TRUNCATED OPEN 
FILE: area, filename 


w 


The user truncated an active file. 


## UN RECOVER I/O 
opib 


A 


An irrecoverable I/O error occurred on the device assigned to the operationol 
label opIb. 


## WRITE PRO opIb 


A 


The file name assigned to the operational label opIb is SY or FG write pro- 
tected and an SY key-in is not in effect. 


## DO NOT ABORT 
DURING SQUEEZE 


w 


SQUEEZE in process. 

— 



For RAD Editor aborts initiated by the RAD Editor itself 
(i.e., not due to an X key-in by the operator), the fol- 
lowing abort message is issued: 

MBKG RE ABORT LOC zzzz 

where 

RE is the RAD Editor abort code. 

zzzz is the location at which the abort occurred 

(if significant). 



messages will be followed by a I {BEGIN WAIT message on 
the OC device (abort otherwise). Only a few of the 
messages ore followed by an unconditional abort (code UT) 
as indicated in Table D-5. 



UTILITY SUBSYSTEM ABORT CODE 

Aborts of Utility Subsystem processing are indicated by the 
following form of abort message. 

IIBKG UT ABORT LOC zzzz 



ummr subsystem messages and abort code 



where 



UTILITY ERROR MESSAGES 



UT is the UTILITY abort code. 



The error messages issued by the Utility subsystem are listed 
in Table D-5. If attend mode is in effect, most of these 



zzzz is the location at which the abort occurred 

(if significant). 
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Table D-5. UHlity Error Messages 



Message 


Meaning 


** BOT opib, device 


An attempt has been made to backspace over the magnetic-tape load 
point or the beginning of a disk file, i.e., BOT was encountered be- 
fore the required number of records or files had been passed. 


** CAL SEQ ERR 


The Utility Executive has encountered a calling sequence error on a re- 
turn from M:READ/M:WRITE. One reason may be an attempt to copy a 
record with an odd byte count onto disk (may occur with BCD 7-track 
tapes). See MrREAD status returns in Chapter 4 of this manual. 


** CKSM ERR oplb,clevice 


A checksum error was detected on a record read from Ul or BI. 


** CORE OVFLO 


The available memory area used for prestoring commands or storing in- 
put records (when the CORE option on the {UTILITY COPY command 
is used) has overflowed. The Utility program aborts. 


** DELETE ERR 


No UI card images were found in the block to be deleted (for !*DELETE 
and !*SUPPRESS commands). Message on DO only unless in attend mode. 


** DEOF oplb,device 


Two consecutive file marks were encountered before the required num- 
ber of records or files hod been passed, i.e., skipped, compared, etc., 
or before the program to be updated had been encountered. 


** EMPTY oplb,device 


Manual intervention is required (the device is in the manual mode or no 
device is recognized). 


** EOF oplb,device 


An unexpected tape mark, end-of-file (disk), or !EOD has been read 
from magnetic tape, cards, paper tape, keyboard/printer, or disk file, 
e.g., before a required number of records was passed. 


** EOToplb,device 


The end-of-tape or end of disk file was encountered before the required 
number of records or files had been passed. 


** ERR AREA 


An invalid RAD area name has been used. 


** ERR FRGD 


An attempt has been made to assign a background operational label to 
a foreground operational label, device-file number, or RAD file. 


**ERR OPLBl 


The operational label to be assigned is invalid. 


** ERR OPLB2 


An attempt has been made to assign one operational label to an invalid 
or undefined operational label or RAD file. 


** IL RAD SEQ oplb,device 


The operational label was inval idly assigned to a random-access or 
compressed EBCDIC disk file, or an attempt was made to skip, read, 
or write more than one disk file. 


** ILLEG BIN oplb,device 


The first byte of a record read from UI or BI did not contain X'FF' 
or X'9F'. 


** INV CTRL 


A l*MODIFY control command was interpreted from SI when the Rec- 
ord Editor was not in the modify mode. 


** INV OPLB oplb,device 


The operational label is not valid. The "oplb,device" portion of the 
message may contain invalid data if input/output is attempted for an 
operational label not recognized by the Monitor. 


** INV I/O OP opib, device 


An input/output operation is not meaningful for the requested 
device. 
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Table D-5. Utility Error Messages (cont.) 



Message 


Meaning 


** I/O ERR oplb,device 


The input/output calling sequence is in error, incorrect length is 
specified, or no input/jutput is pending for a check operation. 


** LD INPUT UI,device 


The modify mode was entered and updating is to be performed. The 
operator responds by mounting the tape to be input and keying-in an 
S response on OC to continue. 


** LD LIST UI, device 


Both SI and UI are assigned to the same device. The operator responds 
by mounting the tape to be listed and changes the state of the device. 


** NO SPARES 


An attempt has been made to define a new background operational 
label but no room is available in the corresponding table. 


** NO name opib, device 


Two consecutive lEODs or tape marks on UI, or one !EOD or tape 
mark on BI were encountered during the editing process before the de- 
sired number of modules had been copied (where "name" is the pro- 
gram name not found). 


** NO name UI, device 


Two consecutive lEODs or file marks (one end-of-file for a sequential- 
access RAD file) are read from UI before the Ob|ect Module Editor has 
inserted, replaced, or deleted all requested modules. 


** OP LB TABLE OVFL 


An attempt has been made to assign or input more than eight operational 
labels. Only the first eight unique labels on an !*OPLB card will be 
entered in the operational label table. 


** PARAM ERR 


Case 1. Update data from SI contains an illegal sequence number; 
that is, a nonnumeric character. An error alarm is also 
listed on LO. 

Case 2. A necessary control command parameter was omitted, or was 
of invalid form (e.g., opIb), or was greater than 32,767. 

Case 3. The ident parameter (on an !*IDENT card) is greater than 6, 
the sequence number parameter is less than 2, or the sum of 
the two parameters is greater than 8. 


** PRE ERR 


The l*PRESTORE command did not follow immediately after the 
!*UTILITY command. 


** PRE OVFLO 


The RAD prestore file on X5 has overflowed. The Utility program aborts. 


** SEQ ERR opib, device 


A sequence error was detected in a record read from SI, UI, or BI. An 
error alarm may be listed on LO also. (Message occurs on OC only if 
attend mode is in effect. ) 


** UNRECOV I/O op lb, device 


An irrecoverable input/output error has occurred after the maximum 
number of retries has been unsuccessfully attempted. 


** UNRECOV I/O UI, device 


An irrecoverable read error has occurred on UI. The partial card image 
input and the message "UI IGNORED RECORD FOLLOWS xxxxxxxx" 
(when xxxxxxxx is the previous nonblank UI ident and/or sequence 
number) is output on LO. 


** UNRECOV I/O UO, device 


An irrecoverable write error has occurred on UO. The card image to be 
output, and the message "UO RECORD OMITTED" or "UO FILE MARK 
OMITTED", are output on LO. 
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Table D-5. U^il!ty Error Messages (cont. 



Message 


Meaning 


** VERIFY ERR op lb, device 


An error has been found by the verification process. When a 
verification error occurs, the COPY routine terminates execution 
of the !*VERIFY command for that device, but continues verifi- 
cation on other input devices. If an error is detected on every 
input device, the VERIFY function is terminated. 


** WRITE PRO opib, device 


An attempt has been made to write on a write-protected magnetic 
tape or RAD file. 
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APPENDIX L USASCII-8 TO EBCDIC-8 CORRESPONDENCE 



\cOL 
ROW\ 





1 


2 


3 


4 


5 


6 


7 


8 


9 


A 


B 


C 


D 


1 

E 


F 





NUL 

0/0 


DLE 
1/0 


KO 

8/0 


K16 

9/0 


SP 
2/0 


& 
2/6 


2/3 


N26 
11/12 


N35 
12/3 


N24 
12/10 


N49 
13/1 


N56 
13/8 


7/11 


7/13 


\ 
5/12 



3/0 


1 


SOH 

0/1 


DCl 
1/1 


Kl 

8/1 


K17 
9/1 


NO 

10/0 


N9 

10/9 


/ 
2/15 


N27 
11/11 


a 

6/1 


J 

6/10 


7/14 


N57 
13/9 


A 

4/1 


J 
4/10 


K31 

9/15 


1 
3/1 


2 


STX 

0/2 


DC2 
1/2 


K2 

8/2 


SYN 
1/6 


Nl 
10/1 


NIO 

10/10 


N18 
11/2 


N28 
11/12 


b 
6/2 


k 
6/Jl 


s 

7/3 


N58 
13/10 


B 
4/2 


K 
4/11 


S 

5/3 


2 
3/2 


3 


EXT 

0/3 


DC3 
1/3 


K3 

8/3 


K19 

9/3 


N2 
10/2 


Nil 
10/11 


N19 
11/3 


N29 
11/13 


c 
6/3 


1 
6/12 


i 
7/4 


N59 
13/11 


C 

4/3 

— — 


L 
4/12 


T 

5/4 


3 

3/3 


4 


K28 
9/12 


K29 
9/13 


K4 
8/4 


K20 

9/4 


N3 
10/3 


N12 
10/12 


N20 
11/4 


N30 
11/14 


d 
6/4 


m 
6/13 


u 

7/5 


N60 
13/12 


D 
4/4 


M 
4/13 


U 

5/5 


4 
3/4 


5 


HT 
0/9 


K5 
8/5 


LF 
0/10 


K21 

9/5 


N4 
10/4 


N13 

10/13 


N21 

1 1/5 


N31 
11/15 


e ° 
6/5 


n 
6/14 


V 

7/6 


N61 
13/13 


E 

4/5 


N 
4/14 


V 
5/6 


5 

3/5 


6 


K6 

8/6 


BS 

0/8 


ETB 
1/7 


K22 

9/6 


N5 
10/5 


N14 

10/14 


N22 
11/6 


N32 
12/0 


f 
6/6 


o 

6/15 


w 

7/7 


N62 
13/14 


F 

4/6 


O 

4/15 


W 
5/7 


6 
3/6 


7 


DEL 

7/15 


K7 

8/7 


ESC 
1/11 


EOT 

0/4 


N6 
10/6 


N15 
10/15 


N23 

11/7 


N33 

12/1 


g 

6/7 


P 

7/0 


X 

7/8 


N63 
13/15 


G 

4/7 


P 

5/0 


X 

5/8 


7 
3/7 


8 


K23 

9/7 


CAN 

1/8 


K8 
8/8 


K24 

9/8 


N7 
10/7 


N16 
11/0 


N24 

n/8 


N34 
12/2 


h 
6/8 


q 

7/1 


y 

7/9 


GO 
14/0 


H 

4/8 


Q 

5/1 


Y 

5/9 


8 
3/8 


9 


K13 
8/13 


EM 
1/9 


K9 

8/9 


K25 

9/9 


N8 
10/8 


N17 

n/1 


N25 

n/9 


\ 
6/0 


i 

6/9 


r 
7/2 


z 
7/10 


Gl 

14/1 


I 
4/9 


R 

5/2 


Z 
5/10 


9 
3/9 


A 


KM 
8/14 


K18 

9/2 


KIO 
8/10 


K26 

9/10 


[ 
5/11 


] 
5/13 


1 
1 

7/12 


3/10 


N36 
12/4 


N43 
12/11 


N50 
13/2 


G2 

14/2 


G8 
14/8 


G14 
14/14 


G20 
15/4 


G26 

15/10 


B 


VT 
0/11 


K15 

8/15 


Kll 
8/11 


K27 
9/11 


2/14 


$ 
2/4 


2/12 


# 
2/3 


N37 
12/5 


N44 
12/12 


N51 
13/3 


G3 

14/3 


G9 

14/9 


G15 
14/15 


G21 

15/5 


G27 
15/11 


C 


FF 
0/12 


FS 
1/12 


K12 
8/12 


DC4 

1/4 


< 
3/12 


* 
2/10 


% 
2/5 


(a) 
4/0 


N38 
12/6 


N45 
12/13 


N52 
13/4 


G4 
14/4 


GIO 
14/10 


G16 
15/0 


G22 

15/6 


G28 
15/12 


D 


CR 

0/13 


GS 
1/13 


ENQ 

0/5 


NAK 

1/5 


( 
2/8 


) 
2/9 


5/15 


1 
2/7 


N39 
12/7 


N46 
12/14 


N53 
13/5 


G5 

14/5 


Gil 
14/11 


G17 
15/1 


G23 

15/7 


G29 
15/13 


E 


SO 

0/14 


RS 
1/14 


ACK 

0/6 


K30 

9/14 


+ 
2/11 


3/11 


> 
3/14 


3/13 


N40 
12/8 


N47 
12/15 


N54 
13/6 


G6 

14/6 


G12 
14/12 


G18 
15/2 


G24 

15/8 


G30 
15/14 


F 


SI 
0/15 


US 
1/15 


BEL 

0/7 


SUB 
1/10 


1 
2/1 


1 

5/14 


3/15 


2/2 


N41 
12/9 


N48 
13/0 


N55 
]3/7 


G7 
14/7 


G13 
14/13 


G19 
15/3 


G25 

15/9 


EO 
15/15 
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APPENDIX F. LINE PRINTER VFCs (WRITE BINARY) 



Pseudo VFC 


Print with Format Definition 


Real VFC 


Print 
Order 


Data Chained to 
Text (Yes/No) 


Printer 
Model 


X'60' 


Print, suppress upspace 


X'60' 


PF 


Yes 


A, B, C 


X'80' 


Print, suppress upspace 


X'60' 


PF 


Yes 


A, B, C 


X'8T 


Print, then space 1 line 


X'CO' 


PF 


Yes 


A, B, C 


X'82'-X'8F' 


Print, then space n lines (2-15) 


1) X'60' 

2) X'CO'+n 


PF 

F 


Yes 
No 


A, B, C 


X'90'-X'9F' 


Print, then skip to channel n 


1) X'60' 

2) X'FO'+n 


PF 
F 


Yes 
No 


A, B, C 


X'AO'-X'AF' 


Space n lines, print and inhibit 
upspace 


1) X'CO'+n 

2) X'60' 


F 
PF 


No 
Yes 


A 


X'EO'+n 


PF 


Yes 


B, C 


X'BO'-X'BF' 


Skip to channel n, print and 
inhibit upspace 


1) X'FO'+n 

2) X'60' 


F 
PF 


No 
Yes 


A 


X'DO'+n 


PF 


Yes 


B, C 


X'CO'-X'CF' 


Space n lines, print and upspace 


X'CO' +n 


PF 


Yes 


A, B, C 


X'DO'-X'DF' 


Skip to channel n, print and 
inhibit upspace 


1) X'FO'+n 

2) X'60' 


F 
PF 


No 
Yes 


A 


X'DO'+n 


PF 


Yes 


B, C 


X'EO'-X'EF' 


Space n lines, print and inhibit 
upspace 


1) X'CO'+n 

2) X'60' 


F 
PF 


No 
Yes 


A 


X'EO'+n 


PF 


Yes 


B, C 


X'FO'-X'FF' 


Skip to channel n, print and 
upspace 


X'FO' +fi 


PF 


Yes 


A, B, C 


Notes: PF - Print with format 
F - Format 

A - Printer models 3451, 7440, 7445 

B - Printer models 7441, 7442, 7446, 3461, 3463, 3464, 3465, 3466 
C - Printer model 7450 

n - Number of lines to skip or channel number. N is limited by line printer capabilities (e.g., a skip 
to channel > 1 for the 7450 line printer will result in a skip to channel 1). 

Invalid VFCs result in a single space((X'CO') operation. 
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INDEX 



Nofre: For each entry in this index, the number of the most significant page is listed first. Any pages thereafter are listed in 
numerical sequence. 



abort codes, 145, 156, 159, 164 
ABS control command (Monitor), 10 
accounting and elapsed time, 5 
ADD control command, 104 
AlO Receivers, 85 
allocation 

core memory, 73, 87 

RAD, 72, 101 

spooling files, 142 
ANS FORTRAN IV, 6 
ASSIGN control command (Monitor), 11 
ASSIGN control command (Utility), 114 
ATTEND control command (Monitor), 13 
automatic dialing (COC), 67 



B 



B (branch) Debug command, 137 

background, 8, 2 

Basic FORTRAN IV, 6 

Basic Spooling System, 141-145 

BLOCK control command, 93 

blocking buffers, 71,93 

branching to service routines, 31 

BSS, 7 

BUFEND control command, 95 



C (debug input device) Debug control, 137 

C: control command (Monitor), 14 

calling COPY, 115 

calling DUMP, 117 

calling Object Module Editor, 119 

calling Overlay Loader, 92 

calling RAD Editor, 104 

calling Record Editor, 120 

calling Sequence Editor, 122 

calling Utility, 112 

card punch, 45 

card reader, 40 

CC control command (Monitor), 14 

CHANGE control command, 121 

Character-oriented Communications (COC) 

equipment handler, 62-67 
checkpoint, 4 

checkpointing background, 86 
CLEAR control command, 108 
COMPRESS processor, 149 
compressed RAD files, 9 
computing library file sizes, 102 
control command diagnostics, 156 



control command. Extended Symbol format, 19 

control command, FORTRAN IV format, 20 

control commands. Monitor, 10-18 

control commands. Processor, 18-20 

control commands. Utility, 113 

Control Panel Task, 76 

COPY control command, 115 

COPY operational labels, 115 

COPY routine, 114 

core layout. Overlay Loader, 89 



D (define) Debug command, 134 

data files, 4 

data files, RAD, 102 

Debug commands, 134 

B, 137 

C, 137 

D, 134 

E, 137 
G, 138 
I, 135 
K, 137 
M, 137 
P, 137 
Q, 137 
R, 136 
S, 135 
T, 136 
X, 136 

Debug control, 133 

Debug error messages, 138 

Debug expansion of instruction, 138 

Debug insertion structure, 139 

Debug processor, 133-140 

DEFINE control command (Monitor), 14 

DELETE control command (RAD Editor), 105 

DELETE control command (Utility), 120 

DPCOPY control command, 106 

DUMP control command (RAD Editor), 107 

DUMP control command (Utility), 117 

DUMP operational labels, 117 

DUMP routine, 116 



E (exit from interrupt level) Debug command, 137 

editing operations, M:COC, 66 

END control command (Overlay Loader), 100 

END control command (RAD Editor), 110 

END control command (Utility), 114 

EOD control command (Monitor), 14 

EXCLUDE control command, 98 



Index 
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Note; For each entry in this Index, the number of the most significant page is listed first. Any pages thereafter are listed in 
numerical sequence. 



EXPAND processor, 149 
Extended Symbol, 6, 19 



F 



F key- in, 28 

FBACK control command (Monitor), 15 

FBACK control command (Utility), 113 

FCOPY control command (Editor), 106 

file name, 4 

files, computing library size, 102 

files, data, RAD, 102 

files, GO and OV, 21 

files, library, RAD, 102 

files, random RAD, 71 

files, sequential RAD, 70 

files, special editing random-access, RAD, 42 

files, special editing sequential, RAD, 41 

files, write on random-access, RAD, 46 

FIN control command (Monitor), 15 

floating accumulator, 9 

foreground, 8,2 

foreground initialization, 80 

foreground l/O queuing, 4,68,85 

foreground priority levels, 78 

foreground priority levels and I/O priority, 84 

foreground programs, 73 

foreground user's Debug capability, 133 

FORTRAN control command (Processor), 20 

FSKIP control command (Monitor), 15 

FSKIP control command (Utility), 113 



G (global symbol table pointer), 138 
GDTRACK control command, 109 
GO and OV files, 21 
Granules, 71 
graph plotter, 147 

H 

HIO, 35 

hardware requirements, (see also RBM/SM Reference 

Manual, 90 30 36) 
HEX control command (Monitor), 15, 132 
hexadecimal patch cards, 132 



I 



I (insert) Debug command, 135 

I/O check, 36 

l/O completion codes, 39 

I/O end action, 68 

I/O initiation, 68 

I/O operations, 68-72 

I/O queuing, 4,68 

I/O recovery procedure, 22 

I/O wait, 85,4 



IDENT control command, 123 
INDUMP processor, 148 
INCLUDE control command, 98 
INITIALIZE control command, 109 
initiating BSS, 142 
input/output task, 76 
INSERT control command, 120,121 



I 



job, 9 

JOB control command (Monitor), 15 

Job Control Processor (JCP), 10 

job step, 9 

JOBC control command (Monitor), 15 



K (keyboard/printer) Debug command, 137 
key-ins, 24, 176,26-30, 147 

BL, 27 

BR, 27 

C:, 27 

CC, 27 

D, 28 

DA, 27 

DB, 27 

DC, 27 

DE, 28 

DF, 28 
DM, 28 
DR, 28 
DS, 28 
DU, 28 
F, 28 
FG, 29 
FL, 29 
FR, 29 
H, 29 
KP, 29 
L, 29 
M, 29 
Q, 30 
R, 30 
RA, 30 
RC, 30 
RD, 30 
RE, 30 
S, 30 
SY, 30 
T, 30 
TO, 30 
UL, 30 
W, 30 
X, 30 
Z, 30 

keyboard/printer, special editing, 41 
keyboard/printer, write, 44 
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numerical sequence. 



LADD control command/ 106 

language processors, 6 

LB control command, 97 

LCOM control command, 98 

LCOPY control command, 106 

LD control command, 97 

LDELETE control command, 106 

LIB control command, 95 

library files, 4, 102,131 

library files, RAD, 102 

LIMIT control command (Monitor), 15 

line printer, write to, 45 

LIST control command, 119, 121 

LMAP control command, 107 

Loader error messages, 158, 100 

Loader l/O abort messages, 158 

loading BSS, 141 

loading foreground programs, T7 

loading nonresident foreground programs, 80 

loading RBM, 130 

loading resident foreground programs, 77 

logical/physical device equivalence, 69 

Long (load) map format, 90 

LRE PLACE control command, 106 

LSQUEEZE control command, 106 



M 

M (modify memory) Debug command, 137 

MiABORT, 49 

MiASSIGN, 56 

MiCKREST, 50 

M:CLOSE, 53 

M.COC, 62-67 

MrCTRL, Aii 

M.-DATIME, 48 

M:DEFINE, 55 

M:DKEYS, 54 

M:DOW, 62 

M:EXIT, 50 

MiHEXIN, 50 

M:INHEX, 50 

M:IOEX, 32 

M:LOAD, 51 

M:OPEN, 52 

MrOPFILE, 60 

M:POP, 59 

M:READ, 36 

M:RES, 59 

M:RSVP, 60 

M:SAVE, 49 

M:SEGLD, 54 

M:TERM, 49 

M:WAIT, 54 

M: WRITE, 42 

machine fault task, 74 



messages, 
messages, 
messages, 
messages. 



magnetic tape, special editing, 41 
MAP, 90 

MAP control command, 106 
MD control command, 98 
memory requirement, DEBUG, 133 
MESSAGE control command (Monitor), 16 
MESSAGE control command (RAD Editor), 110 
MESSAGE control command (Utility), 113 
messages to the operator, boot-time, 130 
messages. Debug error, 138 
Loader error, 158 
Monitor, 22 
RAD Editor, 161 
Utility, 165 
ML control command, 95 
MODIFY control command, 119,121 
Monitor constants, 154 
Monitor control commands, 10 

ABS, 10 

ASSIGN, 11 

ATTEND, 13 

C:, 14 

CC, 14 

DEFINE, 14 

EOD, 14 

FBACK, 15 

FIN, 15 

FSKIP, 15 

HEX, 15 

JOB, 15 

JOBC, 15 

LIMIT, 15 

MESSAGE, 16 

PAUSE, 16 

PMD, 16 

PURGE, 16 

RBACK, 15 

REL, 17 

REWIND, 17 

RSKIP, 15 

TEMP, 17 

UNLOAD, 17 

WEOF, 18 

XED, 18 

XEQ, 18 
Monitor loading, 130 
Monitor messages, 22 
Monitor service routines, 31-67 
Monitor tasks, 73 
Monitor zero table, 152 
MP control command, 95 
MS control command, 95 
multiply/divide exception tasks, 76 



nonresident foreground, 9 

nonresident foreground creation or updating, 131 

nonresident foreground programs, 73 
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nonresident foreground programs, loading, 80 
nonresident section. Monitor, 1 



Object Module Editor control commands, 119 

Object Module Editor operational labels, 118 

Object Module Editor routine, 1 17 

OLOAD control command (Overlay), 92 

operational labels, 1 1 

operational label usage, 150 

operator communication, 22,30 

operator control, 26 

OPLBS control command (Utility), 115 

OV file, 20 

overlay capabilities, 4 

overlay cluster configuration, 89 

overlay cluster organization, 87 

Overlay control commands, 92-100 

BLOCK, 93 

BUFEND, 95 

END, 86 

EXCLUDE, 98 

INCLUDE, 98 

LB, 97 

LCOM, 98 

LD, 97 

LIB, 95 

MD, 98 

ML, 95 

MP, 95 

MS, 95 

PUBLIB, 99 

RES, 98 

ROOT, 97 

SEG, 99 

TCB, 96 
Overlay Loader, 87,6 
Overlay Loader abort codes, 158 
Overlay Loader operational labels, 89 
overlay structure example, 88 



P (selective dumps) Debug commands, 137 

paper tape, special editing, 41 

paper tape, write to, 44 

patches, 132 

PAUSE control command (Monitor), 16 

PAUSE control command (RAD Editor), 110 

PAUSE control command (Utility), 113 

PLOT processor, 147 

plotter, 147 

plotter symbiont, 7 

PMD control command (Monitor), 16 

Power Off Task, 74 

Power On Task, 73 

preparing the program deck, 125-129 



PRESTORE control command, 113 

procedures, I/O recovery, 22 

Processor control commands, 18 

Processor files, 4 

Processor, system, 6 

program, 8 

Protection Violation Task, 76 

PUBLIB control command, 99 

Public Library, 4, 131 

F\jblic Library creation or updating, 131 

PURGE control command (Monitor), 16 



Q (quit) Debug command, 137 
queuing, I/O, 64 



R (remove srKipshot or insertion) Debug command, 136 

RAD allocation, 101 

RAD area mnemonics, 3, 110 

RAD Editor, 101-110,6 

RAD Editor control commands, 104 

ADD, 104 

BDTRACK, 109 

CLEAR, 108 

DELETE, 105 

DPCOPY, 106 

DUMP, 107 

END, 110 

FCOPY, 106 

GDTRACK, 109 

INITIALIZE, 109 

LADD, 106 

LCOPY, 106 

LDELETE, 106 

LMAP, 107 

LREPLACE, 106 

LSQUEEZE, 106 

MAP, 107 

MESSAGE, 110 

PAUSE, 110 

RESTORE, 108 

SAVE, 107 

SQUEEZE, 108 

TRUNCATE, 110 

VERIFY, 108 
RAD Editor messages, 161 
RAD Editor operational labels, 103 
RAD Editor warning messages, 161 
RAD file management, 72 
RAD files, 70 
RAD/disk areas, 3 

RAD/disk pack area organization, 101 
RADEDIT control command, 104 
random access RAD files, write on, 46 
random files, 71 
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random-access RAD files, special editing, 41 

RBACK control command (Monitor), 15 

RBACK control command (Utility), 114 

RBM abort codes, 156 

RBM and foreground user's interface, 133 

RBM boot procedure, 130 

RBM characteristics, 1 

RBM Control Task, 9, 77 

RBM subsystems, 6 

RBM system processors, 6, 18 

RBM/processor interface, 20 

RCOC, 66 

read automatic, 40-42 

read binary, 40-42 

read binary from keyboard/printer, 41 

read binary from paper tape, 41 

real-time priority, M.-READ, 41 

real-time programming, 73-85 

rebooting the system from RAD, 130 

Record Editor operational label, 120 

Record Editor routine, 120 

reentrant routines, 5 

REL control command (Monitor), 17 

RES control command, 98 

resident foreground creation or updating, 131 

resident foreground programs, 73 

resident foreground programs, loading, 77 

resident foreground, scheduling tasks, 77 

resident section. Monitor, 1 

restart, 4 

RESTORE control command, 108 

return registers, M:READ, 37 

return registers, M: WRITE, 44 

return status from M:IOEX, 34 

return status from MrREAD, M:WRITE, M:CTRL, 38 

REWIND control command (Monitor), 17 

REWIND control command (Utility), 114 

ROOT control command, 97 

routines, monitor service, 31 
Abort, MrABORT, 49 

Absolute Core Image Loader, M:LOAD, 51 
Allocate Temp Storage without Transfer, M:RES, 59 
Assign RAD Files, M:ASSIGN, 56 
Character-oriented Communication, M:COC, 62 
Checkpoint/Restart, MrCKREST, 50 
Close RAD File, M:CLOSE, 53 
Convert OPLB to DFN, M:OPFILE, 60 
Date and Time-of-Day, M:DATIME, 48 
Diagnostic Output Writer, M:DOW, 62 
General Control, M:CTRL, 46 
General I/O Driver, M:IOEX, 32 
General Read, M:READ, 36 
General Write, M .-WRITE, 42 
Hex to Integer Conversion, M: HEX IN, 50 
Integer to Hex Conversion, M:INHEX, 50 
Interrupt Restore, M:EXIT, 50 
Interrupt Save, M:SAVE, 49 
Load Overlay Segments, M:SEGLD, 54 
M:COC Service, 62 
Normal Exit from Background, M:TERM, 49 



Open RAD File, MrOPEN, 52 

RAD File Definition, M:DEFINE, 55 

Read Data Keys, M:DKEYS, 54 

Reserve or Release Peripherals, MrRSVP, 60 

Simulated Wait Instruction, M:WAIT, 54 

Temp Storage Release, M:POP, 59 

routines, reentrant, 5 

routines, SYSGEN optional, 147 

RPG, 6 

RSKIP control command (Monitor), 15 

RSKIP control command (Utility), 114 



S (insert snapshot) Debug command, 135 

SAVE control command, 107 

save tape, system, 130 

scheduling resident foreground tasks, 77 

secondary storage management, 3 

SEG control command, 99 

semiresident foreground program, 73 

SEQUENCE control command, 123 

Sequence Editor control commands, 122 

Sequence Editor operational labels, 122 

Sequence Editor routine, 122 

sequential files, 70 

sequential RAD files, special editing, 41 

sequential RAD files, write on, 45 

service processors, 6 

service routines, 32 

SIO, 35 

solicited control, 26 

SORT, 6 

special editing for card reader, 45 

special editing for magnetic tape, 41 

special editing for paper tape or keyboard/printer, 41 

special editing for random-access RAD files, 42 

special editing for sequential RAD files, 41 

spooling system, 141-145 

SQUEEZE control command, 108 

standard background operational labels, 11 

standard foreground operational labels, 12 

standard constants, 153 

standard device unit numbers, 12,69 

startup, system, 130 

status returns for M:COC, 65 

SUPPRESS control command, 123 

symbiont plotting system, 147 

system communication, 22 

system equipment, 1 

system initialization and creation, 5 

system patching, 132 

system save tape, 130 

system startup, 130-132 



T (selective dump) Debug command, 136 
tape, system save, 130 
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task, 8 

Task Control Block (TCB) functions, 80 

task dismissal on wait I/O, 84 

task entrance format, 83 

TCB control command, 96 

TEMP control command (Monitor), 17 

temporary stack, 9 

transfer vector for monitor services, 31 

TRUNCATE control command, 110 



U 



UNLOAD control command (Monitor), 17 
UNLOAD control command (Utility), 114 
unsolicited control, 26 
UTILITY control command, 112 
Utility Control commands, 113 

ASSIGN, 114 

BCOPY, T16 

CHANGE, 121 

COPY, 116 

DELETE, 120,121,123 

DUMP, 117 

END, 114 

FBACK, 113 

FSKIP, 113 

IDE NT, 123 

INSERT, 120,121 

LIST, 119,121 

MESSAGE, 113 

MODIFY, 119,121 

MODIFY SYSTEM, 119 

OPLBS, 115 

PAUSE, 113 

PRESTORE, 114 

RBACK, 114 

REWIND, 114 

RSKIP, 114 

SEQUENCE, 123,124 

SUPPRESS, 123 

UNLOAD, 114 

UTILITY, 111 



UTILITY COPY, 115,116 

UTILITY DUMP, 117 

UTILITY OMEDIT, 119 

UTILITY RECEDIT, 120 

UTILITY SEQEDIT, 122 

VERIFY, 116 

WEOF, 114 
Utility Control Function processor, 113 
Utility error messages, 165 
Utility executive program, 112 
Utility I/O error messages, 165 
Utility operational labels, 115, 1 17, 118, 120, 122 
Utility program organization. 111 
utility programs, 111-124 
Utility source input interpreter, 11 1 
Utility subsystem, 6, 1 11 



VERIFY control command (Editor), 108 
VERIFY control command (Utility), 116 



W 

wait I/O, 85,4 

WEOF control command (Monitor), 18 

WEOF control command (Utility), 114 



X (step snapshot) Debug command, 136 
XED control command (Monitor), 18 
XEQ control command (Monitor), 18 
XSP, 7 
XSYMBOL control command (Processor), 19 



zero table, 152 
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